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(54) Tide: JJJ^^^^TW^^ A LAYERED-HIERARCHY CONTROL STRATEGY DISTRIBUTED imX> 

(57) Abstract 

A process controller (100) implements smart field device standards (132) and 
odicr bus-based architecture standards so that communications and contix)! among 
devices are performed and die standard control operations arc transparent to a user. 
The process controller implements and executes a standard set of function blocks 
(522) or control functions defined by a standard protocol so that standard-^ 
control is achieved with respect to non-standard-type devkres (12), The process 
controller enables standard devices (6) to implement die standanl set of function 
blocks and control functions. The process controller implements an overall strategy 
as if all connected devices are standard devices by usage of a Fieklbus function 
block as a fundamental building block for control structures. Function blocks arc 
defined to create control structures for all types of devices. A user defines the 
control strategy by building a plurality of fimcdon blocks and control modules 
(440) and downloading or installing user-specified portions of the control strategy 
into the Ficldbus devices and die non-Fieldbus devices. TYiereafler. the Fieldbus 
devices automatically perform die downloaded p<»tions of the overall strategy 
mdcpendcntiy of otfier portions of the control statcgy. The process control system 
mcludes a diagnostic monitoring and display f\mctlonaMiy for viewing. In a coherent 
manner, diagnostic infonnation relating to a process that operates over multiple 
devices and system components. TTie digital control system automatically senses when a new controller is attached to a networic and 

I/O Ports that are attached to the new Controller. The digital control sysiJp^J^l^^J^ 
^tanauc configui^on jrogiam that responds to sensing of a new controlter by automatically configuring die input/output WO) subsystem 

^^iLiiv^ 1^ Infonnation on the devices. Tlie digital control system wid, a predetermined configuration 

amon^ca ly senses the conn«:t,on to a networic of a digital device that is not included in the predetermined configuration e 

^^l^nf fir^' From a su^le application routing, a user selects a control from aSZg a plurality of co^U^™ 

^^^^^.S"^ ^^"^ ^ and Stiuctural TfextT to hnplerSent a co^I stK 

SL'S^T*™^ '^a'^ ^^^^ an alarm and event monitoring and display system for which various usJa of the systeTcanS 
pnontize the alarm and event information tftat is displayed. «> i- / / « wic sysran can easily 
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FonranorCand executed onaco,r,„.erorcon.ro.ler. These high^^^ 

process control prognnnming. are not nsuaUy used or understood by process engineers, maintenance 
"gu^cantn>lengin^.opcra.orsandsupeni^^^ Higher level graphical display languages ha>« been 
developed for such personnel, such as continuous function block and ladder logic. Ttus each of the 
"UBi-xr^nuintcnancepcrsonnel.^^^^ 

elcmentsoftheprocesscontrolsystemthat enables the^ 
lesponsibilmes. 

For exan^le.ap,ocess control programnught be written inFortran and r^twi™^ 
caknlatctheaverageoftheinputsandproducean output vah. equal to th^ 
^^couJdbetern«dtheAVERAGEfiurc.ionandnuybein^^^ 
d^playforthecontrolengincers. Atypical gn^phical display nuycons^^ 

u.pute.cneoutpat,andalabeldesig„atingtheblocleasAVERAGE. A different prognunn^y be used to 
oeatcagtaphicalrepresentaUonofthissan^fonctionfor^ 3^,^^^^ 
s,«ent,sdeln.en=dto.hecoston«,.thesesoftwareprognun^ 

selectable features. The prognuns are identified by luncdonblodcs. A user may then invoice a funcdon and 
sdectthepredefined graphical repn^entations to createdifferemviewsforthe ^y 
sdectu^oneofaplurahtyoffiutctionblocksfrontthelftraryforuseind^ 
rather than having to develop a con^rfetely new program in Fortran, for example. 

A group of standardized funcdons. each designated by an associated luncUon block, may be stored in 
a control hbrary. A designer equipped with such a library can design process control sohUions^ 
^lercomiecting. on a computer display screen, various functions or de^^^ 
b ocks to perform particular tasks. The microprocessor or computer associates each of the fimcdons or 
dements definedby the fimction blocks withpredefined templates stored in the l.^r«^ 
I«.giain functions or dements to each other according to the interconnecti^^ 
Ideally, a designer could design an entire process control program using graphical views of predefined 
fi«K:dons without ever writing one line of code inFortran or other high^^^ 

C)neproblemassociatedwiththe«seofgraphicalvie«sforptocesscontn,lpro 
«astmg systems al 10 w only the equipment manufectmer; not a user of thi^ 

control functions, along with assodated graphical views, or modify the predefined fimcti«» within the 
provided libiaiy. 

Newpmcesscontrolfimcdonsarededgnedprimarifybycompanieswhosdl^ 
by the eml users who may havcapartic«h.r need forafimctionthalisnotapartof^ 
tomnssupplicdbythecompar^. The sUu«lardizedfiuK:dons are contained within a control 
fimushedwiththesystemtotheendnser. The end user must dther utilize existing fimcdonssuppUed with 
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the design environment or rely on the company supplying the design environment to develop any desired 
particular customized function for them. If the designer is asked to modify the paiameteis of the engineer's 
view, then all other views using those parameters have to be rewritten and modified accordingly because the 
function program and view programs are often developed independently and are not part of an integrated 
development environment Qearty. such procedure is very cumbersome, expensive, and time-consuming. 

Another problem with existing process control systems is a usage of centraUzed control, fypicaUy 
employing a central controUer in a network, executing a program code that is customized for spedalized, 
user-defined control tasks. As a result, the process control systems are Really constiained to a particiilar 
size and difficult to adapt over time to arising needs. Similarly, conventional process control systems are 
inflexible in configuration, often requiring a complete software revision for the entire system when new 
devices are incoiporatcd. Furthermore, the conventional process control systems tend to be expensive and 
usually perform on the functions initially identified by a user or a system designer that are only altered or 
rqjrogiammed to perform new functions by an expert who is familiar with the entire control system 
configuration and programming. 

What is needed is a uniform or universal design environment that can easily be used, not only by a 
designer or manufachmer but also a user, to customize an existing solution to meet his spcd&c needs for 
developing process control functions. What is fiirther needed is a personal computer-based process control 
system that is easily implemented within substantially any size process and which is updated by users, 
without the aid of the control system designer, to perform new and different control fimciions. 

Many process control systems include local field devices such as vahfes. motors, regulators and the 
like which are responsive to specific control protocols, such as Profibus. Fieldbus, CAN and the like, to 
implement various control fimction routines. Accordingly, these controUcrs are responsive to certain 
standard control protocols to implement control functionality in the field. The use of such standard control 
signal protocols can reduce the time and cflFort of developing a control system because a designer can use the 
same types of control signals from all devices responsive to the control protocol. 



are 
or 

an 



However, certain control devices are not responsive to standard control protocols. These devices 
often responsive to other types of control signals such as digital ON/OFF signals, analog current signab 
analog voltage signals. A system designer either has to avoid using field devices that are nonresponsive to 
installed protocol, or develop systems that operate under one or more protocols. Thus, present day processing 
systems disadvantageously lack a capability to utihze both standard protocol control devices and devices that 
do not respond to control signals defined under the standard protocols. 

What is needed is a process control system that controls both devices that are defined using a 
standard protocol and other, non^otocol devices in a manner that is transparent to the user of the process 
control system. 
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Sysu^ that perfom, monitor, control, and feed back functions in process control environments are 
typically in^^lcmemed by sow writtenin^^ 

Fortran or C and executed on a computer or controHer. These high-level languages, although effective for 
process control programming, art. not usually used or understood by process engineers, maintenance 
engineers, control engineers, operators and s.^^ Higher level graphical di^lay languages have been 
devclopedforsuchpeisomiel.suchascontinuousto^ THus each of the 

engineers, maintenance pcrsomrel, operators, lab personnel and the like, require a graphical view of the 
elements of the process control system that en^^^ 
responsibilities. 

For «an,plc. a process control program nugta be ^tten u. For^ 
calcalatetficavcrBgeoftheuq^tsandproduceancutpu.^^ ^ 

im.gramcouldbeten«dtheAVEIUGEfin„:don and may be invoke 

d^playforthcconuolcagmceis. A typical grapMcal display consist of a recuu,gular block having two 
uqmts.oneo«lput.andalabddesignatingtheblockasAVERAGE. A different program may be used to 
aeateagnvhicaln^resemadaaoftlussan^iunaionforan Bcforethe 
system is ddive«l to ttec»seon«a; these softwareprogmnsaieph^ 
selectable features. The programs are identified by function blodcs. A user may then invoke a fimction and 
sdectthepn^efinedgrapWcalrepresentationstocreatediffeientviewslbrtheo^^ etc by 

sdecting one ofapluralityoffunction blocks fiomthehT,rao. for use in definingapro^^ 
rather than having to develop a completely new pmgtam in Fortran, for example. 

A g««v of standardized functions, each designated by an associated function block, may be stored in 
acontrollibrary. A designer equipped with such a libmiy can design process control solutions by 
interconnecting. onacomp«er display screen, various functions or elements sdecte^ 
blockstoperformparticulartasks. The micropnxxssor or computer associates each ofthefimctions or 
elemems defined by the fimction blocks with predefined templates stored in the libm^^^^ 
program functions or elements to each other acconiing to the intercomiections desire 

IdeaUy.adesigner could design an entire process control program using gnvhical views 
fcaclions without ever writing one line of code inFoxtran or other hi^^^ 

OneprtWemassociated with the,« of graphical views fwproccss^^ 

easting systems anow only the equipment mam,fi«turer,notauser of tto 

controlfimctions.alongwithassociatedgn9,hicalviews.ormodifythepredefinedfm^ 
provided library. 

Newpnx*ssoontn.lfimctions are derignedprimadly by companies who scU designs^ 
l^thecndusenswhomayhaveaparticularneedforafum^tionthatisnotapartofth^ 
fimctionssuppHedlorthecompatty. The standardized fimctions are contained within a «mtrollil«^ 
lunushedwiththesystemtothecmiuser. Tl- end user must either utilize existing fimcdonssuppUed with 
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the design environment or rely on the con^y supplying the design owironment to develop any desired 
paitiailar customized function for them. If the designer is asked to modify the parameters of the engineer's 
view, then all other views using those parameters have to be rewritten and modified accordingly because the 
function program and view programs arc often developed independently and are not part of an integrated 
development environment. Clearly, such procedure is veiy cumbersome, expensive, and time-consuming. 

Another pioUem with existing process control systems is a usage of centralized control, typically 
empl<qdng a central controUer in a netwoik, executing a ptog^ 

user-defined control tasks. As a result, the process control systems ace ^ically constrained to a particular 
size and difficult to adapt over time to arising needs. Similarly, conventional process control systems are 
inflexible in configuration, often requiring a complete software revision for the entire system when new 
devices arc incorporated. Furthermore, the conventional process control systems tend to be expoisive and 
usually pcifoim on the functions initially identified by a user or a system designer that are only altered or 
rcprogrammed to pcrfonn new fimctions by an expert vfho is familiar with the entire control system 
configuration and programming. 

A further problem with existing process control sysUms is that the physical implementation of 
different systems is highly variable, including control devices and field devices that have a wide range of 
"inteUigence". For example, some field devices, such as valves, motore and regulators, may have no 
computational or control capability. Other field devices may have a high level of control autonomy. StiU 
other devices may have some computational strength, but not a sufficient amount to accomplish a desired 
control task. 

What is needed is a uniform or universal design environment that can easily be used, not only by a 
designer or manufacturer but also a user, to customize a control process to the pl^sical constraints of the 
process, utilizing control capabiUties various controllers and devices, supplementing these control capabUities 
wiien desired and distributing control functionality flexibly throu^out the process control system to meet 
spcd&c needs for developing process control fimctions. What is fimher needed is a personal computer-based 
process control system that is casUy implemented within substantially any size process and which is updated 
by users, without the aid of the conUol system designer, to perform new and different control fimctions by 
distributing these control functions throughout the control system including all central, intcmediate and 
peripheral levels. 

Ehagnosuc information is one type of infonnation that is usefid to monitor and display in a process 
control system. However with the various types of devices in a process control system, include 
variety of field devices, diagnostic infonnation is not generally monitored in a consistent manner from one 
device to the next Furthennore. important diagnostic information typically relates to the interaction of 
nnihiple portions of the control system, for example, the combined operations of a controUcr and device or 
nmhiplc devices and conlroUers, Diagnostic information relating to multiple dicuits in a system is lypicalty 
not handled by existing process control systons. 
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Diagnostic infonnaUon is most useful when related to the various control operations that are 
occurring when the diagnostic information is monitored. Conventional process control systems typically 
access and display diagnostic information with no relation to the control operations or control schemes that 
are fimctioiiiitg during diagnostic testing. 

One pr«*lem assodaled with the use of graphical views for diagnostic displ^ is that ensti^ 
systems allow only the equipment manu&cturer. not a user of this equipment, to define the diagnostic 
information to be monitored, along with associated graphical views, or modify the predefined diagnostic 
functions within the provided library. 



a 
a 

a 



What is needed is a uniform or universal design environment that can easily be used, not only by 
designer or manufiicturer but also a user, to customize monitoring and display of diagnostic operations for 
variable number and tn>e of devices and components of a process control system. What is further needed is 
personal computer^ased process control system that includes a flexible diagnostic monitoring and display 
fimctionality that is easily implemented within substantially any size process and which is updated by users, 
without the aid of the control system designer, to monitor and display diagnostic information for various 
combinations of process field devices. 

In a conventional process control system, the local field devices are typically configured in the fidd, 
often by individually programming the local field devices using a hand-held field programmer. Individual 
programming of the field devices is time consuming and ineffidenl and often leads to inconqiatibilities 
between the device configuraUon and the configuration of other devices and controllers in the process control 
system since a global view of the system is more difficult to sustain when individual devices are programmed 
independenUy. Usage of individual programming devices is inconvenient since multiple different 
programming devices Qrpically must be used to program respective different field devices. 

Furtheimorc, local device feihires, including tenqiorary feilures or local power disruptions, internet 
operations of the entire control system, sometimes causing extended downtime since each foiling device must 
be reconfigured locally. 

What is needed is a process control system that allows individual field devices to be configured 
without local, independent prognunming. What is further needed is a process control system which aUows 
configuration of the global systaa from a location remote firom the hxal field devices so that a conqntible 
global configuration is achieved while allowing peripheral elements which are configured in a suitable global 
manner, to operate indqKndoitly to achieve control fimctionalify. 

Configuration of the global system is based on parameters that describe the particular field devices 
that make up the system. However, the control protocols for communicating with the field devices may be 
insufficient to conv^ parameters that are suffidem to configure the system. For example, the system 
management specification of the Fiddbus protocol defines three states for a device including an 
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INmALIZED state, an UMmmALIZED state, and a system management operational 
(SM_OPERATIONAL) state. The three defined slates are sufficient to describe the behavior of a device from 
the peispective of the system management, but are not adequate for describing a device from the perspective 
of either the fieldbns interface or software engineering tools for analyzing, controlling, or disp^ying the 
status of a device. This insufficiency is highly notable when configuration involves the operation of 
commissioning a device that is attached to the Fieldbus link in an UNINITIALIZED state. 

What is fiutha needed is a process oontnd system that differentiates between Fiddbus device slates 
to siqqwTt automatic sensing of devices and online address assignmett of devices. 

Scvaai control languages have been developed under an EC- 1 1 3 1 standard which assist a user in 
implementing a control straU^. These control languages include function blocks, sequential fimclion charts, 
ladder logic and structured text Each of these languages is directed to a particular type of user, including 
control engineers, control system designers, technicians, operators and maintenance workers. TTiese users 
have widely different leveU and areas of experience, training and expertise. Dififerent users typically view 
control systems from greatly different perspectives and seek a solution to veiy different problems; expressed 
in diflfoem manners. For exanqile. a control configuration view of a control system designer may be 
nonsense to a maintenance worker and vioe-veisa. 

What is needed is a user interface which flexibly presents a configuration in a manner that is most 
understandable and usefid to a particular type of user. 

Alarm and event information is one type of information that is highly critical to monitor and display 
in a process control system. However with the various types of devices in a process control system, including 
a wide variety of field devices, alarm information is not generally monitored in a usefiil manner. For 
exan^le. vciy differem urgencies may exist with respect to a particular alarm. Some alarm conditions may 
be indicative merely that some routine servicing should take place without urgency. Other alarm conditions 
leqoire immediate attentiim. Certain devices in the process control system measure highly critical 
conditions while other devices monitor much less urgent information. Furthermore, important some alarm 
conditions may relate to information tiie imeraction of multiple portions of the control system, for example, 
tlw combined operations of a controller and device or multiple devices and oontrolleis. Alarm conditions 
relating to multiple circuits and devices in a system are typically not handled by existing process control 
systems. 

Alarm and event information is most useful when related to the various control operations tiiat arc 
occurring when the conditions are monitored. Conventional process control systems typicalty access and 
display alarm information with no relation to the contanl operations or control schemes titat are fimctioning 
during diagnostic testing. Conventional process control systems genoally do not have a consistent system for 
setting piiori^ of different alarm conditions and events. 
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One problem associated mth the use of graphical views for ahum and event dispbys is that existing 
systems allow only the equipment mamifacturer. not a user of this equipment, to define the alarms and events 
to be monitored, along with associated graphical views, or modify predefined event priorities. Diffident types 
of users may need to visualize different aspects of the process control system. For example, some users have 
a capabiHiy to change only some operating aspects of the control system. These users should have access to 
comlition information which they can control whUe for other events that may be controlled by another user, 
alarm information is not urgently needed. 

What is needed is a uniform or universal design environment that can easity be use4 not only by a 
designer or manu£icturer but also a user, to prioritize dispUy of alarm and event information. 

DISCLOSURE OF INVENTION 

In accordance with the present invention, a process controller implements smart fidd device 
standards and other bus-based architecture standards so that communications and control among devices are 
performed so that the standard control operations are transparent to a user. The process controUer allows 
attachmem to a theoretically and substamially unlimited number and type of field devices including smart 
devices and conventional nowmuut devices. Comrol and communication operations of the various numbers 
and types of devices are performed simultaneously and in paralld. 

The described design environment enables a process control designer or user to modify a standard 
process control fimction or create a unique customized process control function and create the graphical 
views to be associated with the modified or newly created process control function, all within a common 
envinmment The design environment includes a common interface for both the creation of the function and 
for iu associated engineers, operators, hb and maintenance peisomiel or other desired users such that when 
the engineer's fimction is modified or created, the modification or creation manifests itself in all other 
giaphical views of the fimction. In addition, the design enviromnem has a common database structure of 
attributes and methods ami the graphics associated with the process control fimction to aUow modified i 
created process comrol fimctions to be represented in whatever giaphical methodology that is desired < 
required by the designer, whether by ladder logic, contimious fimction block or other design language 
required by the various engineer, operator, lab. and maimenance personnel as other desired giaphical views. 



lor 
loi 
ges 



Maiqr advantages are achieved by the abovenlescribed system and operating method. One advantage 
is that control operations are dispersed throughout the control system, avoiding the inflexibility that arises 
ftom centralized control Another advantage is that the conttol system is pcrsonal<oapiterCPQ based aa4 
therefore, inexpensive in comparison to mainfoune based systems, easily upgraded as additional processes 
added to the system, and conveniently operated by multiple useis. TTie PC-based control is fiutlier 
advantageous in allowing uscr-fticmMy programming and display phufoims such as Windows 9S«* and 
Windows NT™. 



arc 
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In accordance with the present invention, a process conlrolto implements and executes a standaid 
set of function blocks or conUol funcuons defined by a standard protocol so that standard-type control is 
achieved with respect to non-standard-type devices. The process controller enables standard devices to 
implement the standard set of function blocks and control functions. The process controller implements an 
overall strategy as if all connected devices are standard devices by usage of a function block as a fundamental 
building block for control structures. These function blocks are defined to create control structures for all 
types of devices. 

hiany advantages are gained by the described system and method. One advantage is that the system 
is highly uniform, whether attached devices arc standard protocol devices or nonstandard devices, thcrdjy 
improving system reliability. A fiuther advantage is that system development costs are greatly reduced by 
handling various devices in a uniform manner. Another advantage is that a wide range of different field 
devices are supported so that inteUigent devices utilize the intelligent capabiUties and "dumb'* devices are 
controUed by other controllers. An additional advantage is that a software routine performing a particular 
routine is highly re-usable, improving software reliability. 

In accordance with the present invention, a process controller implements an overaU, user-dev^^ 
control strategy in a pnxcss control network that includes distributed controller and field devices, such as 
Fieldbus and non-Fieldbus devices. A user defines the control strategy by building a plurality of function 
blocks and control modules and downloading or installing user-specified portions of the control strategy into 
the Fieldbus devices and the non-Fieldbus devices. Thereafter, the Fieldbus devices automatically perform 
the downloaded portions of the overall strategy ind^endenUy of other portions of the control strategy. For 
cxan^le in a process control sy^cm that includes distributed field devices, controllers and workstations, 
portions of the control strategy downloaded or installed into the field devices operate indq)cndentty of and in 
paraUei with the control operations of the controllers and the workstations, while other control operations 
manage the Fieldbus devices and implement other portions of the control strategy. 

The described process control system and operating method has many advantages. One advantage is 
that the system siqjplies a uniform, universal design environment for users of many various expertise, 
experience and training levels to customize a control process to the plq^cal constraints of the process. A 
further advantage is that the described system uses control capabilities of various controlleis and devices, 
supplementing these control capabilities when desired and distributing control functionality flexibfy 
throughout the process control system as needed Another advantage is that the process control system is 
easily based on a personal computer-based design which is easily implemented within substantial^ any size 
process and which is updated by users, without the aid of the control system designer, to perform new and 
difFerenl control fimctions. This flexibility is achieved by distributing control functions throughout the 
control sjrstem inchiding all central, intermediate and peripheral levels. 

In accordance with the present invonion, a process control system includes a diagnostic monitoring 
and display functionality for viewing, in a coherent manner, diagnostic information relating to a process that 
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operates over multiple devices and system components. Atthougfa the multiple devices and system 

components typically encompass widely diflfeient device types and opeiational standaids. the process control 

system incoiporates diagnostic information relating to all devices and presents tiiis information to a system 

user in a unifonn manner so that an operating control strategy and the diagnostic information are presented 

as though aU control actions and diagnostic information were performed or generated at a single locatioa A 

user-defined diagnostic program is assembled as a set of fimction blocks and control modules and represented 

as a set of layers of intenxnnected control objects identified as modules which include informational 

stmctures accessed as attiibutes. Information is accessed using device hierarchy attribute addressing. 

supporting direct addressing of I/O signak ftom moddes. bypassing the use <rf^^ 
aviMding I/O function Mode bdiavior. 

Many advantages are achieved using the described pitjcess control metiiod. One advantage is tiiat 
the control scheme and the diagnostic monitoring are configured in die system in the same manner, saving 
system resources and improving system reliability. Amrther advantage is Uiat configuration of the 
diagnostics is highly versatile, achieving a wide range of diagnostic behaviois. A further advantage is that 
tiie same display objects and procedures are used to disph^r all types of information inchiding configuration 
information, statiis information, diagnostics and virtiially aiiy other information generated or stored in the 
system. 

In accordance wiflj the present invention, a digital conttol system automatically senses when a new 
controUer is attached to a network and determines the number and types of yo Ports that are attached to the 
new controller. The digital contiol system formats and displays the I/O Port information upon request by a 
user. The digital control system program also includes an automatic configuration program tiiat responds to 
sensingofanewcontronerlqrautomaticallyconfiguringtheinput/output(I/0)subsystem. Theuseraddsa 
new controller without setting any physical switches or nodes. A user optionally supplies configuration 
information for a device into a database, prior to connection of a device. Upon connection of the device, die 
device is automatically sensed and configured using tiie database configuration information, without setting 
of physical switches on the devices. 

In accordance with anotiier ai^ of the invention, a metiiod of automaticaUy sensiitg a connection 
of a controUer to a network and incoipoiating the contndler into a network openting system iocfaides the 
steps of connecting a controller to the network, sending a request fiom the controller to confiim a network 
address assignment, the request being aooompanied by the oomroOer media access control (MAC) address, a 
netwoik configuration service receiving the request to confiim and responding. The network configoration - 
service responds by performing tiie steps of searching a table of configured devices for a matching MAC 
address and. when tiie MAC address matches, generating device and network infonnatioa The device and 
network information includes a netwoik address ftom a device table. When tiie MAC address docs not 
match, netmnk coofigDration service generates device and network information including a netwoik address 
fiom MAC address-based defimU information and adds tiie defoult information to tiie device table. When flie 
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MAC address docs not match, the network configuration sendee fiirther peifoims the step of assigning Uic 
connocted controller under user control either as a new device added to the device table or as a device 
configuration previously existing in the device table. 

Many advantage are achieved by the described qrstem and method. One advantage is that field 
devices arc programmed from a remote location so that individual field setting of the devices, using a local 
setting device, is not necessary. Central prognunmabiUty is highly usefiil to reduce system management costs 
and for reducing downtime of a process control system. A fiirther advantage is that oonfigoration of the 
entire system, rather setting of individual devices, leads to a system in which individaal system settings are 
highly conqmible. 

In accordance with an aspect of the presenl invention, a control system contrvds one « more 
interconnected devices according to a defined control configuration. The control system automaticaUy senses 
a device that is connected to the control system but not included in the control configuration definition. The 
control system supplies initial interconnect information to the connected device sufficient to upload 
configuration parameters ftom the device to the control system. 

In accordance with a flmhcr aspect of the present invention, a digital control system with a 
predetermined configuration automatically senses the connection to a network of a digital device that is not 
included in the predetermined configuration. The digital device is assigned temporary address information 
and placed in a tenqwrary state, called a standby state, in which the digital device sun>ties information to the 
digital control system allowing a user to access the digital device including access of device information and 
configuration parameters. Using the device information and configuration parameters, a user selectively 
commissions the digital device by assigning a physical device tag. and a device address and instalUng a 
control strategy to Uie digital device, Uiereby placing the digital device in an operational state in 
communication witii the digital control system. In the standby state, a user interrogates to determine the type 
of device that is attached, determines the role of tiie device in the context of tiic digital control system, 
assigns a physical device tag that assigns the determined role to tiie device, and verifies connection of Oie 
device to the netwodt Also in the standby state, the user initiates other applications applied to die device, 
inchiding calibration of Uk device and configuring the device within the overall control sdieme of the digital 
control system. 

In accordance with another aspect of the present invention, a control system differentiates between 
Fieldbus device states beyond the states defined according to the Ficldbus standard specification. The control 
■system sets a physical device tag equal to the device identification (ID) for the devices that do not have tags, 
while the device is autoscnsed. A device attached to the Fiddbus link with the physical device tag set c<^ 
to the device ID is controlled in the manner of an UNINITIALIZED device. 

In accordance with an aspect of the present invention, automatic sensing of field devices is extended 
beyond a conventional input/ output level to the configuration of Fiddbus devices by a digital control system. 
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ManyadvaWagesareachievedl^thcdcscribedsystemandnKaM^ One advantage is thai 
configuration of a co«™i system is greatly facilitated. The physical «,mH«ion of a device to the net^A 
auUnHaticaUyinitiatesincinsionoftheconnecteddeviceintoU^^ The described system and 

method advantageously fedliutes confonnity between the configuration of a network and the physical 

5 «««onnectionsof,henetworktiuusen«asthebasisfor.heconfi^^^ Hie described system and 
method assist prognmmring of fidd devices firm a remote location so that individ 
<lev«»s.usingalocal5ettingdcvice.isnotnecessa,y. n« system and method support cemral 
programmability is highly useful ,0 redm* system managemem a«ts and Ib^ 
comrolsystem. A fiuther advantage is that configuntfion of the entire system, rather set.^^ 

' «'«iccs, leads to a system in which individual system settings are hi^ 

Inaccordance with the present invention.apiocessc»ntrol system indudcsauser 
suppom multiple IEC.1131st««lard control languages anduser-sdec^^ 

languages. F"™" single -I^on routine, a user sdects a control language from among a pl^^^ 
contK,! languages inchiding. for example Function Blodcs. Sequential FuncUon Charts. Ladder Logic and 
Stractured Text, to inclement a control stnit^. 

In accordance with another aspect of the present im-ention. a method for configuring a process 
com^leaviromnemcontrolledlyacompater system havingaprocessorconn^ 
indudesthestepof providingaplundityofinstructionalsections. An instmcdonal section sets forth 
•nformationrelatingtoconfiguringtheprocesscontrolenvironmem. The method also indudes the steps of 
sdecung a control language editor for defining a process com«d environment configuration, displaying on 
the display device a sequence of configunuion screen presentations renting to the insm^^^ 
directed m terms of the sdected contrd language editor, and guiding a user through the configuration of the 
process control environmem via the sequence of configuration screen presemations. 

Manyadvantagesareattainedbythedescribedsystemandmethod. One advantage is that many 
differem users are supportedl^ the systemso that users havingawidera^^ 

easUyusethesystem F«>thennore. the system is highly usdbl ft. a single user to tailor various aspects 
the system using a most appropriate language for a particular system aspect 

In acconlance with the preseminvemion.aprocess control system inchides an alarm and 
n«m«oringanddisplaysys.emforwhid.varioususcrsof,hesystem^ 

informationthatisdisplayed. The alarm and event configuration is highly flexible and is configured by a 

«sertoduph^partic«lareventsinahierardricalmam.er.asdirecfedl^the TT« user sets a desired 

alann pnonty. selecting high importance ahmns for more mgem display and amnmda^ 

lowerd^playstatustolessurgentevent. At lognm. a particular^ user is assodated with a display 

configur^on fo, displaying alarm and event infonnadon that is penin^ 

system is automatically ^imed-withcurrentalanns and initu^ 
event occ mi en oes. 
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Many advantages are achieved using the described process contra! method. One advantage is that 
alam iafonnation is presented to a user who can best use that information in a manner directed by the user. 
Another advantage is that a user attains access to the appropriate information automaticaUy. at log-oa A 
fiirther advantage is that the information stream is "primed" when a user logs on so that pertinent alann 
events begin immediate accumulation for that user. 

BRIEP BE SCRIPTIOW OP DRAWINfyi 

The features of the invention beUcved to be novel are specifically set forth in the appended claims. 
However, the invention itself both as to its stnictnre and method of operation, may best be undeirtood by 
referring to the following description and accompanying drawings. 

FIGURES lA, IB and IC iUusHate a screen display, a first schematic block diagram and a second 
schematic block diagram, respectively, process control systems in accordance with a generalized embodiment 
of the prcscm invention which fiimishes a capabi% to create a new control template and a capabUity to 
modify an existing control template for only one view, such as an engineering view. 

FIGURE 2 is a schematic block diagram showing the process control environment in a 
configuration implementation and a run-time implementation. 

FIGURE 3 is a block diagram illustrating a user interface for usage with both configuration and 
run-time models of the process control environment. 

FIGURE 4 is a schematic block diagram which depicts a hierarchical relationship among system 
objects of a configuration model in accordance with an embodimem of the present invention. 

FIGURE 5 is a schematic block diagram which depicts a configuration architecture that operates 
within the hierarchical relationship illusuated in FIGURE 4. 

FIGURE 6 is a block diagram iUustrating an example of an elemental fimction block, which is one 
type of system object within the configuration model definitioa 

FIGURE 7 is a btocfc diagram depicting an example of a composite fimction block, which is anoUier 
lypc of system object within the configuration model A><inition- 

FIGURE 8 is a block diagram iUustrating an example of a control module, which is another type of . 
system object vritiiin the configuration model definition. 

FIGURE 9 is a block diagram showing a module instance, specifically a control module instance, 
»*ich is created in accordance with the control module definition depicted in FIGURE 8. 



FIGURE 10 is a fk>w chart wiiich shows an exan^le of execution of a contnd module at 



tun-lime. 
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ilGURE 11 is a flow chart which shows an example of a module at a highest layer of a control 
stiuctute. 

ncURE 12 is a block diagram which ilhistrates an objectK)riented method for installing a process 
I/O attribute block imo a PIO device^ 

FIGURE 13 is a block diagram depicting an objectK)rient€d method for linking a control module 
input attribute to a PIO attribute. 

FIGURE 14 is a blodc diagram showing an object-oriented method for linking a control module 
output attribute to a PIO attribute. 

FIGURE 15 is a block diagram showing an object-oriented method for reading values of contained 
PIO attributes. 

FIGURE 16 is a block diagram which illustr^ an organization of information for an instrument 
signal tag. 

FIGURE 17 is a flow chart Ulustrating a method for bootstrap loading a control system throughout 
a network in the process control envitoiuncnt 

FIGURE 18 is an objea communication diagram ilhistrating a method for creating a device 
connection for an active, originating side of the connection. 

FIGURE 19 is an object communication diagram illustrating a method for creating a device 
connection for a passive, listening side of the connection. 

FIGURE 20 is an object communication diagram illustrating a method for sending request/ 
reqx>nse messages between devices. 

FIGURE 21 is an object communication diagram illustrating a method of downloading a network 
configiuation. 

FIGURE 22 is a pictorial view of a ftont-of-screen display which illustrates a flowchart of tiie 
operations of a diagnostic display routine, 

FIGURE 23 is an object communication diagram iUustrating a method for one device to check 
whether another device exists on a network. 

nGURE 24 is an object communication diagram iUustrating a metiiod for requesting device 
communications diagnostics. 
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FIGURE 25 is an object communicatioii diagram illustrating a method for requesting device 
connection communications diagnostics. 

FIGURE 26 Uiustrates a method for automatically sensing and incorporating a controller/ 
multiplexer into a runtime system. 

FIGURE 27 is a flow chart ilhistrates steps of an automatic configuration routine for configuring a 
physical I/O device. 

nGURE 28 is a pictorial view of a froiitH)f-scieen dispUQT for a graphical user interfe^ 
displaying a system configuration. 

FIGURE 29 is a state transition diagram illustrating various states of a field device. 

FIGURE 30 is a flow chart illustrating a first operation of commissioning a new device. 

FIGURE 31 is a flow chart illustrating a second operation of commissioning an unbound. 

FIGURE 32 is a flow chart illustrating a third operation of deconunissioning a device. 

FIGURE 33 is a flow chart illustrating a fourth operation of attaching a commissioned device 
without enablement of operational powerap. 

FIGURE 34 is a flow diart illustrating a fifth operation of replacing a device. 

FIGURE 35 is a flow chart illustrating a sixth operation of attaching an UNRECOGNIZED device. 

FIGURE 36 is a flow chart illustrating a seventh operation of decommissioning an unrecognized 

device. 

FIGURE 37 is a flow chart illustrating an eighth operation of placing a decommissioned device in a 
standby condition. 

FIGURE 38 is a sch^natic blodc diagram which illustrates a program stnicture of a process control 
configuration program for defining a process configuration using a plurality of control languages. 

FIGURES 39A through 39E are multiple screen presentations showing configuration, selection and 
choice screens that are iiwoked by a configuration program during operation of a configuration operation 
using a functional block control language and a sequential fimction chart control language. 

FIGURE 40 is an object model showing object relationships of various objects for handling alarm 
and event functions. 
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nCURE 41 is a state transition diagram v*idi depicts alann attribote states. 

nCIIRE 42 is a context diagram showing a context for defining an alarm event witli respect to a 
control module. 

FIGUWE 43 is an objert conmiunication diagram illustrating a method for pe^^^ 
write opexation that evokes an "in alarm" status. 

MODES F OR CARRYING OPT Tmr. INVENTION 

Refiaiing to FIGURE lA. a control system is shown. In general, the system I inchides a main 
processing d<nace. such as personal computer 2. that is connected to a local area netwoA 
local area network card. Although any local area network protocol may be used, a non-pioprietary ethemet 
protocol is beneficial in many applications because it allows for communications with thclocal area network 
3. The local area network 3 is dedicated to carrying control parameters, conuol data and other relevant 
information concerned in the process control system. As such, the LAN 3 may be referred to as an area 

controlled network or ACN3. The ACN3may be comiected to other LANs for sharing informations 
via a hub or gateway without aflGscting the dedicated nature of ACN 3. 

In accordance with standard ethemet protocol, a ploralily of physical devices may be connected to 
the ACN 3 at various "nodes." Each physical device comiected to the ACN 3 is oomiected at a m>de and each 
node is separately addressable according the LAN protocol used to implement ACN 3. 

To establish a redundant system, it may be desirable to construct ACN 3 fiom two or more ethemet 
systems such that the &ilure of a single ethemet or LAN system wifl not result in the fiiUure of the entire 
system. When such "redundant ethemets" are used the feihire of one ethemet LAN canbe detected and an 
alternate ethemet LAN can be mapped in to provide for the desired flmctionalily of ACN 3. 

The main personal computer CPC") A forms a node on the ACN 3. The PC 2 may. for example, be 
a standard personal computer running a standard operating system such as Microsoft's Window NT system 
Main PC 2 is configmed to generate, in response to user input commands, various control routines that are 
provided via the ACN 3 to one or more local oontroUeis identified as element 4 and 5 which implement the 
conirolslratcgy defined bylhecontrol routines selectedandestabHshedininainPCr Main PC 2 may also 
be configured to implement direct comrol routines on field devices such as pmnps, valves, motors and the 

Kke via transmission across the ACN 3. rather than through a local controller 4 or 5. 

Local controllers 4 and S receive control routines and other configuration data through the ACN 3 
fiom PC 2. The local controllers then generate signals of various types to various field devices (such as 
pumps, motors, regulator valves, etc.) 6 through 15 which actually implement and perform pineal steps in 
the field to implement the control syston esublished by the routines provided by PC 2. 
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Two types of Add devices be connected to local controller 4 and 5 including field devices 6 
through 10 which are responsivB to spedfic control protocol such as FieldBus. Profibus and the like. As 
those in the art wUl appreciate, there are standard control protocols (e.g. FieldBus) according to which 
specific protocol instructions arc provided to a protocol-friendly field devices (e.g.. a Fieldbus field devices) 
wiU cause a controller located within the field device to implement a specific fimction corresponding to the 
protocol fimction. Accordingly, field devices 6 through 1 1 receive protocol specific (e g., FieldBus) control 
conmiands firam either the local controUers 4 and 5 or the personal computer 2 to inqilement a field device- 
spedfic fimctioiL 

Also connected to local controUers 4 and 5 are non-protocol field devices 12 through 15, which are 
referred to as non-protocol because they do not include any local processing power and can respond to direct 
control signals. Accordingly, fidd devices 12 through 15 are not capable of implementing fimctions that 
would be defined by specific control protocol such as the FieldBus conuol protocol. 

Functionality is suj^lied to allow the non-protocol fidd devices 12 throu^i 15 to operate as 
protocol-fticndly (e.g.. FieldBus specific) devices 6 through 11. Additionally, this same fimciionality allows 
for the inqilementation of the protocol-specific control routines to be distributed between the local fidd 
devices 6 through 1 1, the local controllers 4 and S and the personal computer 2. 

The distribution of protocol-spedfic control routines is illustrated in more detail in FIGURE IB. 
FIGURE IB rders to one portion of the system shown in FIGURE lA, specifically tiie personal computer 2, 
the ethemet 3, local controller 4, a smart field device 6 and a dumb device 12, in greater detail. 

Personal computer 2 includes program software routines for implementing standard fiinctional 
routines of a standard control protocol such as the FiddBus protocol. Accordingly, personal computer 2 is 
programmed to receive FieldBus commands and to implancnt all of tiic fimctional routines for which a local 
fidd device having FieWbus capabilities could inq)lemenL The ability and steps required to program 
personal computer 2 to inq>lemeat FiddBus block functionality wiU be clearly apparent to one of ordinary 
sidllintheart. 

Connected to personal computer 2 by the ethernet 3 is local conUoUer 4. Local controUer 4 inchides 
a central processing unit connected to a random access memory which provides control signals to configure 
the central processing unit to implement appropriate operational functions. A read only memory is conneaed 
to tile random access memory. The read only memory is programmed to indude control routines which can 
configure ttie central processing unit to implement all of the fimctional routines of a standard control protocol 
such as FiddBus. Personal computer 2 sends signals Uuough ctiiemet 3 to tiie local controlla^ 4 viiuch 
causes one, more or aU of the programmer routines in the read only memory to be transferred to tiie random 
access memory to conQguxe the CPU to inq}lenient one, more or all of the standard control protocol routines 
such as the FiddBus rontines. 
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•Die smart fidd device 6 Includes a central prooesdne unit which implements certain control 
fimciions. If the devices is. for example, a FieldBus device tlKn the central processing unit associated 
the field device 6 is capable of implementing all of the RddBus functionality requirements. 

Because the local coniiuUer4 has the ability to implementFieldBus specific con^^^ controlIer4 
operatessothatnon-protocoldevicellactsandisoperatodasaFieUBusdevice. For example, if a cantrol 
routine is running dther in personal computerZor on the a>U of local controUer 4. to^ 
implement and provide FiddBus commands to FiddBus device 6 and non^irotocol device 12. operating as a 
Rddbns device. Since field device < is.a FiddBus device, device 6 receives these commands and thereby 
implements thecontrolfimcUonalitydictatedbythosecommands. Noni,rotocol device 12. however. works 
in conjuncdon with the central processing unit of local controller 4 to implement the RddBus requirements 

such that the local controUer in combination with the fidd deWce implements and operates RddBus 
commands. 

In addition to allowing non-ReldBus device 12 to act and operate as a FiddBus device, the 
described aspect allows far distribution of RddBus comrol routines throughout the system 1 shown in 
nCDRElA. For example, totheextentthatacontrolroutineinitiallyrequestsfidddcvicefitoimplemen^ 
more than one FiddBus control routine, the system 1 allows for control to be divided between the local 
controUer 4 and the local controller 5 such that a portion of the FiddBus control routines are bdng 
implemented by local controUer 5 and other FiddBus routines are implemented by the use of the FiddBus 
routines stored on local controller 4. The division of FiddBus routine implemenution may allow for more 
sophisticated and fi«er control and more efficient utiBzation of the overall processing power of the 
Still fiuther. the fart that personal computer2has the *ility to implcmem FiddBus control r 
FieMBus routines are further distributed between the local controller 4 and the personal computer 2. In this 
mamier. the system aUows personal computer 2 to implement one or all of the FieldBus routines for a 
particular control algorithm. 

Still fiirther. the system allows for the implementation of FieldBus controls to a non-HddBus device 
com«xted directly to the etherndathrough use of the FieldBus control routines stored on person 

2in the same mam«r that FieldBus routines ansimplememed on non-FicldBusdeWce 12 through use^ 
RddBus routines stored on local controlln 4. 

A process comrol emironment 100 is shown in FIGURE IC and iUustrates a control enviromnenl 
for implememing a digital control system, process controUer or the like. The process control enviromnent 
100 includes an operator workstation 102. a laboratory workstation 104. and an engineering workstation lOfi 
dectricaUy imercomiected by a local area networicCLAN") 108 for transferring and recdving data and 
control signals among the various workstations and a plurality of comroUer/multiplexers 110. n,e 
^««kstations 102. 104. 10« a« shown connected by the LAN 108 to a plurality of the controUei/multipl, 
llOthatdectricallyiMerfeccbetweentheworicstationsandapluraUtyofprocesseslll. Inmultiple 
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embodiments, the LAN 108 includes a sin^e woikstation coimectcd directiy to a controller/multiplexer 1 10 
or ahernativdy includes a phiraUty of woikstaiions, for example three woricstaiions 102. 104, lOd. and many 
contmllei/multiplexers 1 10 depending upon the puiposes and requirements of the process control 
environment 100. In some embodiments, a single process controller/multiplexer 110 controls several different 
processes 112 or alternative^ controls a portion of a single process. 

In the process control environment 100, a piocess control strategy is developed by creating a 
software control sohition on the engineering workstation lOd, for example; and transferring the solution via 
the LAN 108 to the operator wockstatton 102, lab workstation 104, and to controUer/multiplexer 110 for 
execution. The operator wodkstation 102 and lab workstation 104 si^ty interim d^ 
control/monitor strategy implemented in the controlleiyimultq)lexer 1 10 and communicates to one or more of 
the controUer/muWplexers 110 to view the processes 112 and change control attribute values according to the 
requirements of the designed solution. The processes 112 arc formed from one or more field devices, which 
may be smart field devices or conventional (non-smart) field devices. The process 1 12 is illustratively 
depicted as two Ficldbus devices 132, a HART (highway addressable remote transducer) device 134 and a 
conventional field device 136, 

In addition, the operator workstation 102 and lab workstation 104 commnnicate visual and audio 
feedback to the operator regarding the status and conditions of the controlled processes 112. The engineering 
workstation 106 includes a central processing unit (CPU) 116 and a display and input/output or user-inteiface 
device 1 18 such as a keyboard, light pen and the like. The CPU 116 typicaUy includes a dedicated memory 
117. The dedicated memory 117 includes a digital conttol system program (not shown) that executes on the 
CPU 116 to implement control operations and functions of the process control environment 100 shown in 
FIGURE IC. The operator woricstation 102, the lab workstation 104 and other workstations (not shown) 
within the process control environment 100 include at least one central processing unit (not shown) which is 
electrically connected to a display (not shown) and a user-interface device (not shown) to aUow interaction 
between a user and the CPU. In one embodiment, the process control environment 100 includes workstations 
implemented using a Motorola 68040 processor and a Motorola 68360 communications processor running in 
companion mode witii tiie 68040 with primary and secondary ethemet ports driven by the 68360 processor 
(SCCl and SCC3 respectively). 

The process control environment 100 also includes a template generator 124 and a control template 
library 123 which, in combination, form a control template system 120. A control tenq)late is defined as the 
' grouping of attribute functions tfiat are used to control a process and tiie mediodology used for a particular 
process control function, Uie control attributes, variables, inputs, and ou^ts for tiie particular fiinction and 
the graphical views of the function as needed such as an engineer view and an operator view. 

The control template system 120 includes the control template library 123 that communicates with 
tiie template generator 124. The control tenqjlate library 123 contains data representing sets of predefined or 
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existing oontrol tcmpUtc functions for use in process control programs. The control template functions 
the templates that generally come with the system from the system designer to the user. THe template 
generator 124 is an interfece that advantageously allows a user to create new control template functions or 
modify existing oontrol template fimctions. The created and modified template functions are selectively 
stored in the control ten^late library 123. 

The template generator 124 indudes an attributes and methods language generator 126 and a 
graphics generator 128. The attributes and methods language generator 126 suppUesdisphy screens t^^ 
allow the user to define a phiraliQr of attribute functions associated with the creation of a new control 
template function or modification of a particular existing control template fimction. such as inputs, outputs, 
and other attiibates. as weU as providing display screens for enabling the user to sdect 
that perform the new or modified function for the particular control template. TTie graphics generator 128 

fbrnishes a user capabi% to design graphical views to be assodated with particular contt^^ 

utilizes the data stored by the attributes and methods language generator 1 26 and the graphics generator 128 

tocompletelydcfinetheattributes.methods.andgraphicalviewsfbracontroltemplate. Tlwdata 
representing the created control temphite function is generally stored in the control template Ubrary 1 23 and 

is subsequemly available for selection and usage by an engineer for the design of p^ 

The process control environment 100 is implemented using an object-oriented fiamewoik. An 
object^riented fiamewoik uses objeo-oriented concepts such as class hierarchies, object states and object 
behavior. These concepts, which are briefly discussed below, are weU known in the art AdditionaUy. an 
objecl-orienled fiamework may be ivritten using object-oriented programming languages, such as the C++ 
programming language, which are well-known in die art. or may be written, as is the case witti tite preferred 
embodiment, using a non^bject programming language such as C and implementing an objectK)riented 
fiamewoik in that language. 

The building Mock of an object-oriented fiameworic is an object An object is defined by a state and 
abcbavior. The state ofan object is set forUi by fields of the object The behavior of an object is set forth by 
methods of the object Each object is an instance ofadass. which provides a temptate for the object Adass 
d^nes zero ormore fidds and zero or more methods. 

Fields are data structures which contain information defining a portion of the state ofan object 
Objects wfaidi aro instances of tire same dass have the same fields. However, tiie particular information 
contained withinthefiddsoftheol^xtscanvaryfromobjecttoobject Each fidd can contain infonnation 
that is direct, sndi as an integer value, or indirect, sudx as a reference to anoUier object 

A method is a collection of computer instructions whidi can be execmed in CPU 1 16 by comprt^ 
system software. Hie instructions of a metiiod are executed. Le.. tfie method is performed, when software 
requeste Uat ti.e object for which tite metiiod is defined perfi,rm tire mettuKL A medrod can be pafenned by 
aigr object tiiat is a member of ti»e class tiiatinchmestiiemetiiod. The particutar object performing the 
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method is the rcspondcr or the responding object When perfonning the method, the lesponder consumes 
one or more arguments, i.e.. input data, and produces zero or one result, i.e.. an object returned as output 
data. The methods for a particular «*ject define the behavior of that object 

Classes of an object-oriented ftaoiewotk are organized in a class hierarchy. In a class hierarchy, a 
class inherits the fields and methods which are defined by the superclasses of that class. Additionally, the 
fields and methods defined by a dass are inherited by any subclasses of the dass. I.e., an instance of a 
subclass includes the fields defined by the superclass and can perfonn the methods defined by the superclass. 
Accordingly, when a method of an objea is caUed, the method that is accessed may be defined in the dass of 
which the object is a member or in any one of the superclasses of the class of which the object is a member. 
When a method of an object is called, process control environment 100 selects the method to run by 
examining the class of the object and. if necessary, any superclasses of the object. 

A subdass may override or sqiersede a method definition which is inherited from a superclass to 
enhance or change the behavior of the subdass. However, a subclass may not supersede the signature of the 
method. The signature of a method includes the method's identifier, the number and type of arguments, 
whether a result is returned, and. if so. the type of the result. The subclass supersedes an inherited method 
definition by redefining the computer instructions which are carried out in performance of the method. 

Classes which are capable of having instances are concrete classes. Classes which cannot have 
instances are abstract classes. Abstract dasses may define fields and methods which are inherited by 
subdasses of the abstract classes. The subclasses of an abstract class may be other abstract dasses; however, 
ultimately, within the class hierarchy, the subdasses are concrete classes. 

All classes defined in the disclosed preferred embodiment, cxcqjt for mix-in classes which are 
described below, are subdasses of a dass. Object Thus, eadi dass that is described herein and which is not 
a mix-in class inherits the methods and fidds of dass Objed. 

The process control environment 100 exists in a configuration modd or configuration 
implementation 210 and a run-time model or run-time implementation 220 shown in FIGURE 2. In the 
configuration implementation 210. the component devices, objects, interconnections and interrelationships 
vrithin the process control environment 100 are defined. In the run-time implementation 220, operations of 
the various component devices, objects, interconnections and interrdationships are performed. The 
configuradon implementation 210 and the lun-time implementation 220 are interc«mnected by downloading. 
The download language creates system objects according to definitions supirficd by a user and crc^ 
instances from the siqtplied definitions. Spedfically, a completdy configured Device Table rdating to each 
device is downloaded to all Woikstations on startiqt and when the Device Table is changed. For controUeiy 
multiplexers 110. a downloaded Device Table only indudes data for devices for which the conttoUei/ 
multqdexer 1 10 is to initiate communications based on remote module data configured and used in the 
spedfic controUer/ multiplexer 1 10. The Device Table is downloaded to the contioUer/ multiptexr 1 1 0 
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when other configuratioii data is downloaded. In addition to downloading definitions, the download 
language also uploads instances and instance values. The configuration implementation 210 is activated to 
execute in the lun-time implementation 220 using an installation procedure. Also, network communications 
parameters are downloaded to each device when configuration data arc downloaded and when a value is 
changed 

The process control cnvironmwit 100 inchides multiple subsystems with several of the subsystems 
having both a configuration and a nm-time implementation. For example, a piocess graphic subsystem 230 
siqiplies u$ca--dcfined views and operator interiadng to the architecture of the process control environment 
100. The process graphic subsystem 230 has a process graphic editor 232, a part of the configuration 
implementation 210, and a process graphic viewer 234, a portion of the nm-time implementation 220. The 
process graphic editor 232 is connected to the process graphic viewer 234 by an intersubsystem intcrfece 236 
in the download language. The process control environment 100 also indudcs a control subsystem 240 which 
configures and installs control modules and equipment modules in a definition and module editor 242 and 
which oucutcs the control modules and the equipment modules in a run-time controller 244. The definition 
and module editor 242 operates within the configuration implementation 210 and Uie run-time controller 244 
operates witiiin the run-time inq>lementation 220 to supply continuous and sequencing control fimctions. The 
definition and module editor 242 is connected to tiie run-time controller 244 by an intersubsystem intcrfece 
246 in the download language. The multiple subsystems are interconnected by a subsystem interface 250. 

The configuration implementation 210 and die run-time implementation 220 interface to a master 
database 260 to support access to conunon data structures. Various local (non-master) databases 262 
interface to the master database 260. for example, to transfer configuration data from the mast^ database 260 
to the local databases 262 as directed by a user. Part of the master database 260 is a persistent database 270. 
The persistent database 270 is an object whidi transcends time so tiiat the database continues to exist after 
the creator of the database no longer exists and transcends space so that the database is removable to an 
address space that is different from the address space at which the database was created. Theentire 
configuration implementation 210 is stored in the persistent database 270, 

The master database 260 and local databases 262 are accessible so that documentation of 
configurations, statistics and diagnostics are available for documentation purposes. 

The run-time implementation 220 interfaces to the p^stent database 270 and to local databases 
262 to access data structures formed by the configuration implemwitation 210. In particular, the run-time 
implementation 220 fetches selected equipment modules, displays and tiie like from the local databases 262 
and the persistent database 270. The run-time implementation 220 interfaces to otiier subsystems to install 
definitions, tiicrd)y installing objects tiiat are used to create instances, when Uie d^tions do not yet exist, 
instantiating run-time instances, and transferring information from various source to destination objects. 
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Device Tables are elements of the configuration database tbat are local to devices and. in 
conrfjination, define pan of the configuration implementation 210. A Device Table contains information 
regarding a device in the process control environment 100. Information items in a Device Table include a 
device ID, a device name, a device type, a PCN network number, an ACN segment number, a simplex/ 
redandant communication flag, a controller MAC address, a comment field, a primary internet protocol (IP) 
address, a primaiy subnet mask, a secondaiy IP address and a secondary subnet mask. 

Referring to FIGURE 3, a blodc diagram illustrates a user interlace 30p for usage with both the 
configuration and run-time models of the process control environment 100. Part of the user interface 300 is 
the E3splQTCt^ 310, an interfering program defined under the Windows NT"' operating system which 
features a device-based configuration approach. Another part of the user inicrfecc 300 is a module definition 
editor 320 for interfedng using a control-based configuration approach. 

The E3q)Iorer™ 310 is operated by a user to select, construct and operate a configuratioa In 
addition, the Ej^lorer^M 310 supplies an initial sUte for navigating across various tools and processors in a 
network A user controls the Explorer™ 310 to access libraries, areas, process control equipment and 
security (^rations. HGURE 3 illustrates the relationship between various tools Uiat may be accessed by a 
tadc operating witiiin tiie process control environment 100 and die relationship b<^een components of tfie 
process control environmenl 100 such as libraries, areas, process control equipment and security. For 
example, when a user selects a "show tags" ftmction from within an area, a "tag list builder" is displayed, 
showing a list of control and I/O flags. From flic tag list builder, the user can use an "add tag" function to 
add a module to a list, thereby invoking a ''module editor". 

Referring to FIGURE 4, a schematic block diagram iUustrates a hierarchical relationship among 
system objects of a configuration model 400. The configuration model 400 includes many configuration 
aspects including control, I/O, process graphics, process equipment, alarms, history and events. The 
configuration model 400 also includes a device description and network topology layout 

The configuration model hierarchy 400 is defined for usage by a particular set of users for 
visualizing system object relationships and locations and for communicating or navigating maintenance 
information among various system objects. For example, one configuration model hierardiy 400, specifically 
a physical plant hierarclty, is defined for usage by maintenance engineers and technidans for visualizing 
plg^cal plant relationsh^)s and locations and for communicaling or navigating maintenance information 
among various instruments and equipment in a physical plant An embodiment of a configuration model 
hieaarclTf 400 Uiat forms a physical plant hierarchy supports a subset of the SP88 pl^sical equipment 
standard hierarchy and includes a configuration model site 410, one or more physical plant areas 420, 
equipment modules 430 and control modules 440. 

The configuration model hierarchy 400 is defined for a single process site 410 which is divided into 
one or more named physical plant areas 420 that are defined within the configuration model hierarchy 400. 
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The physical plant areas 420 optionally contain tagged modules, each of which is uniquely instantiated 
within the configniation model hierarclQr 400. A physical plant area 420 optionally contains one or more 
equipment modules 430. An equipment module 430 optionally contains other equipment modules 430, 
oontrol modules 440 and function blocks. An equipment module 430 includes and is controlled by a control 
5 template that is created according to one of a number of different graphical process control programming 
languages including continuous function block, ladder logic, or sequential function charting ("SFC). The 
configuration model hierarchy 400 optionally contains one or more control modules 440. A control module 
440 is contained in an 6bject such as a physical plant area 420 , an equipment module 430 or another control 
module 440. A oontrol module 440 optionally contains objects such as other control modules 440 or function 
10 blodcs. The oontrol module 440 is thus a container class, having instances which are coUections of other 
objects. The control module 444 is encapsulated so that all of the onntentj; and the impl^enft^ti on of the 
methods of the control nmdule are hidden. 

Referring to FIGURE 5, a schematic blodc diagram shows a configuration architecture 500 that 
operates within the configuration model hierarchy 400 illustrated in FIGURE 4. The configuration 

15 architecture 500 indudes a several objects and classes at multiple levels of abstractiort At an organizational 
level of abstraction 510, the configuration architecture 500 includes a site dass 512 which contains ''named** 
objects and dasses within the configuration architecture 500. Named objects and classes are definitions, 
^dsplsy components such as screens and graphics and other items. The named objects and classes include 
function blocks, us^ aooounts, modules, plant areas, events, libraries and other site-wide information. 

20 Examples of named items are block definitions, equipment module definitions, control module definitions, 
plant area names and the like. 

At a primitive levd of abstraction 520, the configuration architecture 500 includes primitives that 
define the interfaces to functions within the configuration architecture 500, including hard-coded functions 
such as The primitive level of abstraction 520 indudes the classes of functions 522 and parameters 524. 

25 Functions 522 are operational fimctions at the lowest level of abstraction in the configuration ardutecture 
500. Functions 522 are typically coded in the C or C-H- languages. In one embodiment of the configuration 
architectare500, the full set of in^lcmentedfimction blocks 522 are primitives. Objects and classes at the 
primitive level of abstraction 520 are defined throughout the site class 512. Parameters 524 are classes and 
objects at the lowest level of abstraction in the configuration architecture. Parameters 524 indnde integer 

30 numbers, real numba:s, vectors, arrays and the like. Attribute values are mapped into parameters 524 for 
usage within a fimction blodc 522. In one embodiment, function blocks 522 at the primitive level of 
abstraction 520 iru;lude the function block primitives listed in TABLE I, as follows: 

TABLE L Function Rlockx 







1 Action 


Handles simple ajgrignmcut statements i«ing A defined 
expression capabili^. 


1 ADD 


Simple Add function with extensible inputs. 
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• Af 

AI 


FF Standard Analog Input 


: Aft «*A 

: Ai Lite 


A scaled back version of the FF analog input. 


1 AIHART 


The FF Standard Analog Input with some extra abili^ to 
handle HART devices. 


AND 


Smipic And function with extensible inputs. 1 


1 AO 


FF Standard Analog Output (From FF standard specification) \ 


Arithmetic 


rr oianoara Antnmetic Block. (From FF standard 
specification) | 


i BDE TRIGGER 


Simple bi*diicctional edge trigger. i 


[ BIASGAIN 


FF Standard Bias/Gain. (From FF standard specification) 


CALC7L0GIC 


Advanced calculation and logic block that has its own 
language as well as the ability to handle simple ST (1 13 1). It 
has extensible innuts extensible mitmitc anH tiw» aViiittv t^k 
create temporary variables. 


Condition 


Handles simple condition statements using The defined 
expression c^ability. 


Counter 


Simple up/down couiUer that handles several different 
Accumulation methods. 


CTLSEL 


FF Standard Control Seleaor. (From FF standard 
specification) 


DI 


FF Standard Discrete Input. ^From FF standard specification) 1 


• DI Lite 


A scaled back version of the FF discrete input 


: DIVIDE 


Sinq)le Divide. 


j DO 


FF Standard Discrete Output (From FF standard specification) | 


1 DT 


FF Standard Deadtime with advanced control research 1 
implemented, (From FF standard specification) 


i Dtol 

1 


A boolean fan in that converts up to 16 discrete inputs to a 16-1 
bit integer value. Also has some special abilities for capturing 
input patterns. \ 


1 FDLT 


Simple filter. 

s 


j H/LMON LIMIT 


Single high/low signal monitor and limiter. 


^ INTEGRATOR 


rr ouuiuara iniegraior oiocK. (rrom rr standard 
specificatioiO 


ItoD 


Boolean fan-out Takes a 16-bit integer and translates it into 
16 discrete outputs. 


L/L 


FF Standard LeadLag with 2 additional types of equations to 
select (From FF standard specification) 


LOOP 


An I/O snH r^/intrnl K1<vlr unfh tK«» oKila^^^* A f l>TT\ Ar^ 

u\j <uiu V4J11UU1 olouK. wiui inc aoiiiues oi J\±j arkXJf anci AO 
rolled into one block. 


LOOPD 


An I/O and control block with the abilities of DI, Device 
Control, and DO rolled imo one block. 


j MAN 


FF Standard Manual Loader. (From FF standard specification) j 


j MULTIPLEX 


Simple multiplexor with extensible inputs. 1 


i MULTIPLY 


Simple multiply with extensible iiqrats. 


! NDE^TRIGGER 


— » 

Simple negative edge trigger. \ 


NOT 


Simple not | 
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1 function Bl/jfk , . ,-; , : OcscdiUlon/ConuHm^f ^: ^ " - 


i OFF DELAY 


Simple ofr*dday timer. 


1 ON^DELAY 

^ 


Simple on-delay timer. ) 


j OR 


Simple logical or with ext^isible ii^uts. I 


1 P/PD 


FF Standard P/PD, (From FF standard spedficatioa) \ 


j PDE^TOIGGER 


Smiple positive directional edge trigger. \ 


j PERIOD 


Simple monitor that triggers when an input is true for a 
^)ecified period 


I rl 


FF Standard Pulse Input (From FF standard specification) 


rlu 


FF Standard PID with many additions including the ability toT l 

Choose algorithm oi)c, form, and Structure. (From FF standard 
specification) 


1 RAMP 


Simple lan^ generator. 


IRATELIM 


Smiple rate limiter generator 


: RATIO 


FF Standard Ratio blode (From FF standard specification) I 


RETENTIVE 


Single retentive timer. ' \ 


I RS 


Simple reset dominant flip-flop. 


RUN AVE 


Simple rumung average calculator. 


SCALER 


Simple scaler. ? 


SIGC^N 


Generates square waves, sin waves, random waves, or any 
combination of the three. 


1 SIGNALCHAR 


FF Standard Signal Characterizer fFrom FF standbirri ^ 
specification) 


1 SIGSEL 


Single signal selector. 


j SPLnTER 


FF Standard Splitter. (From FF standard specification) 




Single set dominant flip-flop. 1 


\ SUBTRACT 


Simple subtract block. ! 


TP 


Smiple timed pulse block. 


TRANSFER 


Simple transfer block. 


XOR " ^ 


Simple exclusive or block. "| 



At a definition and usage level of abstraction 530. the configuration aichitecture 500 includes 
definitions 532 and usages. Definitions 532 and usages, in combination, define the algorithm and the 
inteifece for objects including fimction blocks, control modules, equipment modules, links and attributes. 
The definitions 532 define algorithms and interiaces for fimction blocks, modules, links and attributes. 
Usages are objects and classes at the definition and usage level of abstraction 530 that represent the usage of 
one definition within another. 



At an instance level of abstraction 540, the configuration architecture 500 includes instances, which 
are "tagged" items within the configuration. Plant areas 542. modules 544. attributes 546. and PIO blocks 
548 are tagged instances. Instances are defined according to definitions 532. AiilantarBaS42iq,reseiitsa 
geographical or logical segmentation of a process site dass 512. All objects and classes at the instance level 
of abstraction 540 arc defined throughout the plant area level so that aU module instances have a 0 or 1 
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association with a plant area 542. To be instaOcd in a run-timc system, the module instances must have a 1 
association, meaning that the module is viewed as being "contained b/* or "scoped" in this context of a plant 
area, A module instance 544 is an installable object that is associated to a specific object of plant equipment 
An attribute instance 546 is a visible parameter in a module instance 544, a plam area instance 542 or other 
device An attnbute instance 546 may be used for an input signal, an output signal, data storage or the like. 

At a device level of abstraction 550, the configuration architecture 500 includes devices 552 such as 
controUers, smart devices and consoles, and input/oulput dervices (JLO) 560 such as a PlOblodc, and the like, 
which represent physical process control equipmcm in the physical plant A process input/output (PIO) blodc 
is an abstraction that represents various high density and low density conventional iiQ)ut/output devices 
including Hart, FieldBus and other inpm and output devices that arc interfaced into the configuration 
architecture 500, High or low density relates to the number of channels on an I/O card. For example, 8 
diamiels are typical on a low density card while a high density card msy have 32 channels. Devices 552 are 
process control equipment in the configuration architccUire 500 and include objects such as controUers, 
input/ou^ devices, consoles and the like. Input/output devices ffO) 560 are the physical process input and 
output devices in the configuration architecture 500. 

A smart device is a field device that is implemented to transmit and receive digital dau pertaining to 
a device, including data relating to device cahTiration, configuration, diagnostics and maintenance. 
T^ically, the smart device is also adapted to transmit a standard analog signal that is indicative of various 
information including, for example, a process value measured by a field device. Exan^les of smart field 
devices include field devices which follow a HART (highway addressable remote transducer) protocol, a 
Fieldbus protocol, a Modbus protocol and a device net protocol. 

Various hierarchical relationships among system objects are implemented to fedUtate navigation 
through the process control environment 100 shown in FIGURE IC by dificrent users and to accomplish 
different tasks. Four different hierarchical relationships are defined induding conuol, control system, 
operations and physical plant hierarchies. A specific system object may be implemented in multiple 
hierarchical systons. 

The control hierarchy is a subset of a standard SP88 hierarchy and has system objects inchiding site, 
physical area, equipment module, control module and control element objects. The control hierarchy is used 
to organize control operations and to define the scope of named objects, A user interacts with the control 
hierarchy on the basis of a site instance, equipment module definitions, control module definitions, a plant 
area instance, equipment module instances, control module instances, display module instances, and process 
VO module/block instances, having signal tags. 

The control system hierarchy indudes operator/configuration stations, host computeis, controlleis, 
I/O devices, smart devices, gateways and the like, vHudk are associated using various netwoik standards 
induding area control netwoik (ACN), process control netwoik (PCN) and other I/O netwoik standards. In 
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oneembodiinent, the ACN hardware incliides staiHlari 104)ase-T ethcmct com^ 
workslationcontainssiandanlEthcnuaiCM^se-Tmteifiicecardsand Auscrintenictswith 
the control system hierarchy on the basis of a defined site instance, a networic definition, a defined netwodc 
instance, devices, and subsystems such as files, cards, channels. controUcis. operation stations, and Fieldbus 
segments. 

The area control netwrk (AChO indudes oommunicatioB fimctionalily al tro 
conunnnications (BOQ level and a low level coramamcatioiis level ROC level oonHoIs the tnteifice between 
the Programmed ^^ipUcations and the ACN communications system. The low level oommunications su{qx>it 
the inteifiice with the TCPAP sockets and the actual transmission of messages. 

Remote Objcrt Commnnications (ROQ are system operations supporting communication of objects 
in the process control em«omnent 100 shown in HGDRE IC and particubrly supporting commmucation 
betweenobjectswhethertheobjectsresideinthesamedeviceorinremotedevi^^ The ROC communication 
level supports communications message services including request/ie^nse. unsolicited reporting, 
evrat/alarm reporting and broadcast message service. 

Reqnestmesponse is a semce by which appUcations semi messages to a remote device and receive a 
response ftom the device. Unsolicited Reporting is a service for periodically sending tq)dated date to a 
remote device. Unchanged data is not reported. Event/Alarm Reporting is a guaranteed delivoy message 
service which is used for the transmission of events, abrms and other vital information for deliveiy to a 
remote device. The broadcast message service is used to send messages to all Program application devices on 
the communications network. The ROC level also sets communications poUdes for the communications 
subsystem. This means that it is responsible for managing what message get sent and when as weU as how 
incoming messages are processed. Communications flow control vriU also be the responsibiU^ of the ROC 
poitioiL 

Low level comnumications support is included for device connection management. ACN redundancy 
and communications systems diagnostics. Device connection management establishes a communications 

connectionbetwecntwodevicesandmanagcsthetiansmissionofmessagesbetweenthetwodevices. ACN 
Redundancy handles the detection of commnnications link feilures. controls the switchlrom one Unk to 
another and tracks the status of communication links between a host device and connected remote devices. 
Communications subsystem diagnostics tracks communication integiily and statistical infonnation. responds 
to requests for oommunications diagnostic data. 

Device connection management in an ACN communications system supports bofliUDP and TCP 
^device connections. UDPconnalkms arc used for normal real time data transfers be^ TCP 
connections are used for special appUcations using a sircaming protocol such as file transfers, device flash 
dowiOoads, and the like. Communications between devices is managed by a DeWceCcmneciion Object The 
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Device Connection Object transmits data and maintains the status of tlie communications links between t«fo 
communicating devices. 

All normal device connection message traffic is directed Uirough a single UDP commnnications 
port. A Device Connectioa Object staits the communications system by creating the communication sock« 
associated with this UDP port as weU as creating the queues needed for management of the device connection 
message tiaflBc. Tlw Device C<mnectionOlqect receives aUinconung messages on a Device Connectio 
comnnmications socket and routes messages to the proper device connection instance for process The 
Device Connection Object handles timing fimctions of device connection^ incfaiding noti^ng device 
connecdon instances when messages time out waiting to be acknowledged, when oonummications link 
checks are due and when device connection resyncs have timed out. 

UDP type communications aie used for the transfer of real-time data among devices. The remote 
object communications (ROC) subsystem passes messages to a UDP Device Connection for transmission to a 
destination device. A pool ofmessagebufEsts is created on startup of each device. The message pool is used 
for aU data transferred between devices, preventing the communications subsystem from exhausting memoiy 
and ensuring that no other task exhausts memory, thereby preventing the communication subsystem fiom 
running. Communication flow control is implemented in the Device Connection Object If the number of 
message buflfers in the communications buffer pool reaches a predefined low level, all remote devices are 
inhibited from sending messages until the low buffer problem is resolved in the affected device preventing 
loss of messages. 

TCP-type communications are used for appUcations using a streaming-type protocol such as file 
tiansfers and device flash downloads. TCPHype connections ate temporary connections established for the 
duration of the applications needs and terminated once the application has completed a communications task. 
For reasons of interoperability, compatibility, and availability, a TCP/IP protocol stack is enqihyed. The 
TCP/IP stack snjplics a connection-oriented, byte stream protocol (TCP) and a connectionless, message 
oriented protocol (UDP). The device connection supports request/response messages. unsoUdted data, and 
event and alarm daU between devices. The communication system maintains tiie device connection through 
one of two available commnnications links in the event of a single communications failure, typically a cable 
fettlt Detection rf a fault and swihA to an ahemate communications path transpires in a short, deterministic 
time span which is less than one second. 

The qierations hierardiy is defined for a particular set of users, specifically operators and 
maintenance cngmecrs, gencraUy for the purpose of accessing displays, reports, and other informational 
items. A user interacts witii tiie operations hierarchy on the basis of a site instance. User Groi^ definitions, a 
Idant area instance, equipment module instances, control module instances, display instances; and rq»ort 
instances. 
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The physical plant hierarchy is defined for a paiticular set of useis. specifically maintenance 
engineers and technicians, typically for the purpose of determining physical relationships among objects and 
navigating maintenance information about plant instruments and equipment. A user interacts with the 
physical plant hierarchy on the basis of a site instance, a maintenance area instance, a plam area instance, 
room instances, cabins instances, node/device instances and display instances. 

The system objects that are implememed in the imUtipie hierarchical systems 
phiraUty of subsystems inchiding control, process VO, control system harthwaie. ledmidancy management, 
event/alam management, history services, process graphics, diagnostics presentation, user enviiomnent. 
managemem organization and field management system (FMS) subsystems. The control subsystem inchufcs 
nmtines for configuring, installing and executing wntrol modules and equipment modules. The process I/O 
subsystem is a nnifoim interfece to devices inchiding HART, Fieldbus. conventional 1/0 and otiier 
input/output systems. The control system hardware subsystem defines a control system topology, devices 
within the topology and capabilities and functions of tiie devices. The control system hardware subsystem 
also includes objects and data structnres for accessing device level information imlicative of states and 
diagnostics. 

The redundancy management subsystem establishes a ledmidant context between primary and 
secondaiy control applications and manages switching in context between the primary and secondary cortrol 
applications. The redundancy managemem subsystem also maintains and monitors redundant context 
diagnostic information inchiding state information and data latenqr information. Network redundancy is 
accomplished using two separate Efliemet communications links or networks. The primary communication 
link is the preferred communications patii. The secondaiy link is only used if tiie primary has fiiiled. 
Communications switchovers ate performed on a per device basis. For example, if device A is 
communicating with devices B and C and tfie primary link to device C feiU. device A continues to 
communicate with device B on the primary link but switches to the secondary link to communicate with 
device C. Each Ethernet link is a separate, dedicated network having a dedicated set of IP addresses and a 
subnet mask 

The device connection olgect manages redundant communications including controlling wbea to 
switch to U« secondaiy link ami when to switch back to tticprimaiy link. Each devic* in die process comrol 
system tracks the communication statais of all cmiem Unks to remote devices by periodically sending Jink test 
messages when no other communications is occurring, to check die status of tiie communications links to 
each device. Rcdondancyswitdiovers are peifonned on a device connection basis. 

The event^larm management subsystem configures, monitors, and suppUes notification of 
significamqrstemstates,actaiowledgmcntsandprioritycalcnlations. The histoiy services stibsystem stores 
amlretricvesprooessandeventinformatioa The process graphics subsystem supplies user-defined views for 
dispIayandoperatorimcilacingontotiKdefincdqrstemaichitett^ The diagnostics presentation 
subsystem fiunishes displays of diagnostic information, typically at tiie request of a user. Heuser 
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environment subsystem sqipiics a user intcrfecc, allowing a user to enter commands to control operation of 
the process control environment 100 shown in FIGURE IC The management organization subsystem sets 
an organizational stracnire of the process control environment 100 inchiding specification of site, area, 
primitives, access to user hT)raries. and location of defined objects and instances. The FMS supplies user 
into^ces, views, and organization structure for the configuration, installation and monitoring crfHART and 
Fiddbus devices. 

A Fieldbus device implements localized control of a process within the process, i n contrast to a 
longer-used and more conventional approach of oontroUing device functions torn a main or centralized 
digital control system. A Fieldbus device achieves localized control by including small, localized controllci/ 
muhiplexers 110 which are closely associated with field devices within the Fieldbus device. The small, 
, localized controllers of a Fieldbus implement standardized control functions or control blocks which operate 
on the field devices within the Fieldbus device and which also operate on other smart field devices that are 
connected to the Fieldbus device. 

Thus, the process control environment 100 implements smart field device standards, such as the 
Fieldbus HI standard. Profibus standard, CAN standard and other bus-based architecture standards so that 
commnnications and control among devices, particularly Fieldbus devices, are performed so that Fieldbus- 
type control operations are transparent to a user. 

The process control environment 100 allows attachment to a substantially unlimited number and 
type of field devices including smart devices, such as Fieldbus and HART devices, and conventional non- 
smait devices. Control and communication operations of the various numbeis and types of devices are 
advantageously performed simultaneously and in parallel 

The process control environment 100 implements and executes a standard set of function blocks or 
control functions defined by a standard Fieldbus protocol, such as the Fieldbus HI standard, so that smart- 
type control is adiicved with respect to non-smart-^ devices, such as a HART device 1 34 and a 
conventional device 136. In addition, the process control environment 100 enables Smart devices to 
implement the standard set of function blocks and control fimctions. Advantageously, the process control 
environment 100 implements an overall strategy as if aU connected devices are Smart devices. This 
inq)lemeniation is achieved, in part, by the usage of a function block as a fimdamcntal bwlding block for 
control structures. These fiinction blocks are defined to create control stnictures for all types of devices. 
Usage of function blocks as fundamental building blocks is described in FIGURES 6, 7, 8 and 9. 

The process control environment 100 implements an overall, user<developed control strategy 
through the definition of fanction blocks and control modules by downloading or installing specific portions 
of the control strategy into smart devices and non-smart devices. Thereafter, the smart devices automatically 
perform the downloaded portions of the overall strategy indq)endent]y of other control system operations. 
For example, the portions of the control strategy downloaded or instaUed into the devices operate 
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indepeadenily of and in parallel mth the control operations of the conliolta/ multiple«is 1 10 and the 
ivorkstations. while other control operations manage the smart devices and implement other portions of the 
control strategy. In effect, the process control enviromnenl 100 implemcms a conuol strategy using the 
GODtKMat multiplaffirs 110 within the smart devices. 

An example of a block diagram defining a fimction blodc of the functions 522 shown in HGURE 5 
isiU«stratedinFIGURE6. Specifically. nCURE 6 depicts an «demental- function block defW 
which is defined to contain only primitive objects. The demenial function Mode definition 600 ddines a sum 
function and indodesa"+»prinutive610.afirstiBp«attnTmte«2wMchisafirst^ 
the primitive «0, and a second input attribute 622 which is a second parameter 624 applied to the primitive 
610. The primitive 610 produces a result that is supplied as an output attribute 630. In this example, the 
elemental fimction block definition 600 is a blodc definition that is created and named SUM. 

A second example of a block diagram defining a fimction blodc of the fimctions 522 shown in 
nCURE 5 is illustrated in FIGURE 7. SpedficaHy. FIGURE 7 depids a "composite" fi,«aion blodc 
definition 700 which is defined to contain one or more elemental fimction Modes 600 and. optionally, one or 
more primitive objeds. The composite fimdion block ddinition 700 defines a composite sum fimction ami 
indndcs a first SUM elemental function block 710 and a second SUM elemental fimdion block 712, each of 
which is the same as the SUM dcmental fimction blodc 600 illustrated in nCURE 6. TTie composite 
fimdion Mode 700 has a first input attribute 720 and a second input attribute 722 wWch are respedive first 
and secoml parameters 724 and 726 applied to the first SUM elemental fimdion block 710. The first 
etemental fimdionblodc 710 pnxluces a result that is applied to the second SUM elemental fimction blodc 
712 as a first parameter 730. The composite fimdion blodc 700 has a thiid input attribute 728 that is a 
secoml parameter 732 appUed to the second SUM dcmental fimction blodc 712. The second SUM dememal 
fimdion blodc 712 produces a result that is suppUed as an output attribute 734. In this example, the 
composite fimdion Mode ddinition 700 is a blodc definition that is created and named SUM3. 

An example of a blodc diagram defining a control module of tiie control modules 440 shown in 
MGURE 4 is iUustrated in WGURE 8. Spcdfically. HGURE 8 depicts a comrol module definition 800 
whidi is defined and contains various input attributes 810. demental fimction blocks 820. a first SUM3 
composite fimdion blodc 830 ami a second SUM3 composite fimdion blodc 832. The exemplaiy control 
module 440 indudes five input attributes 810 whidi are conneded to five respedive dememal fimdion 
blodcs820,threeofwhidiarBpanmu!tasappfiedtothcfirstSUM3conqiosite n,cfiBt 
SUM3 composite fimdion Mode 830 prodnoesaiesult that is suppUedasaparamder to the seco^ 
composite fimdionblodc 832 in combination with paramrteis supplied by the rcmainiijg two elemental 
fimctionblodcs820. The second SUM3 composite fimdion blodc 832 prodnccs a lesuU that is supplied as an 
outpm attribute 840. In this examplt^ the comnd module 800 is a control module ddinition that is created 
and named CMl. 
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Exaiiq)les of block diagrams defining a module instance of the module instances 544 shown in 
nCURE 5, specifically a control module instance, are shown in FIGURE 9. Control module instances 910 
and 920 are cnsatcd in accordance with the CMl control module definition so that each control module 
instance 910 and 920 inchides five input attributes 912 and 922, respectively, that correspond to the five 
input attributes 810 shown in FIGURE 8. Each control module instance 910 and 920 also includes one 
ou^ atUibute 914 and 924, respectively, that correspond to the output attribute 840 shown in FIGURE 8. 
In this example, the control module instances 910 and 920 are control module instances that are created and 
tagged CALCl and CALC2, leqiectively. 

Using a definition editor, a system user creates and names definitions, such as the SUM elemenlal 
fimction block definMon, the SVM3 composite function block definition and the CMl control module 
definition- Then, using a module editor, the system user creates and tags instances, such as the CALCl and 
CALC2 control module instances. 

Referring to FIGURE 10, a flow chart shows an exanq>le of control module e^Kcution at run-time. 
A run-time prognun includes a scheduler routine. Scheduler routines are weU-known in the computing arts. 
The scheduler routine requests execution 1010 of a composite control module, for example the composite 
control module 440 with tag CMl shown in FIGURE 8. The CMl composite control module 440 initiates 
transfer 1012 of the input attributes 820. causing any associated links, or attribute associations, to tiansfer 
1014. A database definition typically refers to "associations" while a runtime definition relates to "links". In 
Steps 1016 through 1056 the CMl composite control module 440 requests each elemental function block 820. 
first SUM3 composite fimction block 830 and second SUM3 composite block 832 to execute in turn. 

Specifically, in stq> 1016 the CMl composite control module 440 requests each elemental fimction 
block 820 to execute. The elemental fimction blodcs 820 initiate transfer 1018 of input attributes, for 
example first iiqiut attribute 612 shown in HGURE 6. The input atuibutes of the elemental fimction blods 
820 request 1020 loading of values fiom the links transferred in step 1014. The links copy 1022 values from 
source attributes to destination attributes. The elemental fimction blocks 820 execute blodc algorithms 1024. 
Upon completion of block algorithm execution, the elemental fimction blocks 820 initiate tiansfer of output 
attributes 1026. for example output attiibute 630 shown in FIGURE 6. 

In stqi 1028 the CMl composite control module 440 requests fiist SUM3 conqwsite fimction block 
830 to execute. First SWM3 conqwsite fimction block 830 initiates transfa 1030 of iqiut attributes, for 
example input atbibutes 722. 724 and 726 shown in HGURE 7, from the elemental fimction blocks 820. In 
step 1032, first SUM3 composite fimction block 830 requests internal fimction blocte. for «cample. the first 
SUM elemental fimction block 710 and the second SUM elemental fimction Wock 712 shown in FIGURE 7, 
to execute in ttirn. First SUM elemental fimction block 710 reads input attributes, executes aMock algorithm 
and sets an ouqmt attribute in slep 1034. Second SUM elemental fimction block 712 reads input attributes, 
executes a block algorithm and sets an output attribute in step 1036. First SUM3 composite fimction block 
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«30initiates.nu«ferofoutpmatditatcsm«cpl03«. The o«pul attribute of first SUM3 composite 
function block 830 requests an associated link to copy the value fro^ 

In Step 1042 the CMl composite control module 440 requests second SUM3 composite function 
block 832 to execute. Second SUM3 composite (unction block 832 initiates transfer 1044 of ii^ut attributes 
fh,mthelinkscomiectedtothefiistSlJM3compositefunctionblock830outpmatm^ Instep 1046. 
second SUM3 composite fimction block 832 requests imernalfan^^^ 

elemental function block 710 and the second SUM elemental function btock 712 shown in FIGBRE 7. to 
execute in turn. Rist SUM elemental funrtionbloci 710 reads input att^ 

and sets an output attribute in Step 1048. Second SUM elemental function block 712 reads input attributes. 
executesablockalgorithmandsetsanoutputattributeinsteplOSO. Second SUM3 composite fenctionbteck 
832 initiates transfer of outpm attributes in step 1052. The output attribute of second SUM3 composite 
function block 832 tequestsanassociatedlinktocopy the value from the output attribute in step 1054. 

In Step 1056 the CMl composite control module 440 initiates transfer of output attributes and output 
attribute 840 requests a link torn second SUM3 compodte function block 8 
. SnM3compositeluactionblock832o«^mtaltribmes. fa some cmbodimems. output fonction blocks push 
output values to a user-configured PIO block attribute (not shown). Thus. PIO attributes are "pufled" by 
function blocks while output function blocks push output values to PIO Block attributes. Similariy. input 
function blocks pull input attribute vahies from PIO Bhick attributes. 

A user defines a module control strategy by speci^ng function blocks that make up control modules 
anddeterminethecontrolstrategy. The user modifies or debugs a module control strategy by adding, 
modi^ng and deleting fimction blocks, configuring parameters associated with the function blocks ^ 
creating a view to new attributes. 

By defining function blocks and control modules, a user-defined conuol strategy. appUcation 
program or diagnostic program is represented as a set of layere of imercomiected control objects identified as 
nmdules. A layer of the control strategy inctades a set of modules which are intertomtccted in a user- 
specified mamter. Amoduletjfpicallyincludesanalgorithmforperfbimingaspcdficfimcti^ 
componemswhichareuscdtodisplayinformationtoauser. A module is optionally represented to incfade a 
set of input and output connections for connecting to other modules. A module maybe considered to be a 

•^lack box-' which perforins a spedfiedfimction and is a)nnected to other modules va 
output connections. 

Referring to HGURE 1 1, a display screen saves as a flow chart which shows an example of a 
'noduteorappIicationpi,«ramLOOPSlM1060atahighcstlayerof^ TTu: iUustrated layer 

of the LOOPSIM 1060 application program includes an input attribute (AIM) module 1062 caDed All, a 
dcadtime module 1064. a proportional, imegral. differential (PID) coMiol module 1066. an output attribute 
(AOUT) module 1068andasimnlatemodute 1070. Each of the illustrative modules im:hmes named input 
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connections and output connections which arc connected to the other modules via lines. The set of modules, 
the input connections and the ou^>ut connections of the set of modules, and the inteiconnections between 
modules define the operation of the LOOPSIM 1060 application. 

At a lowest level, a module is a set of interconnected function blocks. At higher levels, a module is 
a set of interconnected submodules which, in turn, may include a further set of submodules. For example, the 
PBD control module 1066 is Qiiically a set of imeicomiected submodules which perform the different 
functions included in a FID functionality. The input and output connections of the FID module 1066 are an 
input connection and an omp\n connection of one or nunc of the submodules within a next lower layer of the 
FID module 1066. The submodules in the FID module 1066 optionally Include other input and output 
connections sufficient to define the interconnections between the submodules. 

An application, a module or a submodule, at any module level, is optionaUy modified by a user to 
perform a slighUy diflFerent fonction or to perform the same fonction in a dififerent manner. Thus, a user 
optionally modifies the module, thereby modifying the control structure, in a desired manner. SpedficaUy, a 
user optionally adds input and ou^ connections to modules and extends the input and output connections of 
a module to a higher level module so customize modules for various applications. For example, a user 
optionally adds a new input connection or output connection to the FED module 1066 to the "edge" of the FID 
module 1066 which makes the input connection and output connection appear as input and output 
connections to the FID module 1066. 

The process control environment fadUtatcs the definition and modification of the control structure 
by furnishing editing operations in a plurality of control languages including IEC-1 13 1 standard languages 
such as Field Blocks, Sequential Function Charts (SFC), Ladder Logic and Structured Text Accordingly, 
different types of users, from different control backgrounds use the diflfeient languages to write different 
modules for implementing the same or different applications. 

Control modules are specified to have several advantageous characteristics. Some conUol modules 
allow direct access to attributes. For example, some attributes, called "heavy" attributes, support direa 
(maximum performance) communications. Direct communications are advantageously used for connecting 
fimction blocks and Control Modules, supporting event/alarm detection, and high performance trending, for 
example. Some attributes are created automatically iqx>n definition of a control module with a user having 
the option to promote or force a parameter to be exposed as an attribute of a Control Module. OUier 
parameters are made accessible through a module, such as a Control Module, an Equipment Module, a PIO 
Block, or a Device, which contains the parameter but direct communications performance of the attributes 
does not warrant tiie overhead incuried in supplying this pcrfonnan These paramctci^ are advantageously 
accessed to supply information relating to control system tuning, debugging and maintenance. In some 
embodiments, tiicse parameters arc accessed by a general purpose parameter browser appUcations, viliich use 
services provided by tagged containers to reveal attributes, invokeable services, and subcomponents within 
the containen. 
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Rfifoiing to FIGURE 12, a block diagram ilhisinites an objett-onented method for instaUing a 
process I/O attribute block into a PIO device through the operatioa of the control subsystem. A Wock of 
defined objects 1110 includes a site object 1112, a controUer device 1114. a controUer I/O subsystem 1116. a 
PIO interface device 1 1 18 and a PIO device 1 120. Prior to instaUation of the PIO device, the controller VO 
subsystem 1116 is previously created. The PIO device 1 120 is also previously created, either by installation 
or downloading. The blodc of defined objects 1110 directs a detail pointer 1122 to a list of block definitions 
U24 to specify a partiailar type of oyect to be created by a create pointer 1126 dir«^ 
create block 1128. m block definitions 1124 includes a HO input attributes (AIN) block definition either 
as hanhriredorby previous installation. Attributes ofthe specified object are set by a user through the 
opeiationofaB editor 1130. Wor to installation ofthe PIO device^ an input attribute (AIN) bk)ck 1132 does 



not exist 



Prior to instalUng the Am block 1132.auser creates the PIP device 1120 then sets up initial 
for AIN Wock adributes using the editor 1130. The user also sets a period for view panmicter acquisition. 
The AIN block 1132 is saved and then installed. 

Referring to FIGURE 13, a block diagram iUustrates an object-oriented method for linking a 
Control Module input attribute to a process VO attribute. Prior to linking of the control module input 
attribute to the PIO attribute, the PIO block AIN 1220 is previously installed and the control module 1210 is 
also installed. The user specifies that a PIOIN attribute 1212 of the control module 1210 is coraiected to an 
attribute input process variable PV 1214 and requests that a link be made. A link 1216 is made as the control 
module finds the PIOIN attribute and returns a corresponding attribute index, locates PIO AIN in a plant 
area, find the process variable PV attribute and returns a corresponding attribute index, instructs the lun-time 
linker 1216 to create a link with a source at the process variabte (PV) 1214 and a destination at the PIOIN 

attribute 1212, creates the link and comtects the link 1216. At end of a download, links are resolved by the 
linked objects. 

Rfif«aring to FIGURE 14, a block diagram shows an object-oriented method for linking a control 
nuxhile output attribute (AOUT) 1312 attribute to a PIO output attribute (PIOAOUD 1320. A control 
module 1310 is previously installed and the control module output attribute (AOUT) 1312 is installed within 
the control module 1310. The user spedfies that the control module oxHput attribute (AOUT) 1312 is 
eonnfictedtotheaPIOoutpHta«ribntc(PIOAOUT) 1320. The link is made as the run-time implementation 

of the control moduk mo is sent a message to form the connection, the control module 1310 finds the 
AOUT attribute, requests location of the PIOAOUT attribute 1320, creates a link 1322 and connects the 
AOUT attribute 1312 and die PIOAOUT attribute 1320 to the link 1322. 

Referring to FIGURE 15. a block diagnun shows an objectH)riented method for reading values of 
contained PIO attributes. A WO btock 1410 is previously instaUed and an output attribute (AOUO 1412 is 
previously installed within thePIOblockMlO. Auser. for example an engineer, requests a detailed view of 
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the block in which aU attribute values aic displayed. The detaUed display inchides one or moie sets of 
display groups, also called view definitions, associated with the PIO block 1410. A proxy is pieviously 
established for the PIO Block 1410. A user requests detail for the output attribute (AOITT) 1412. Attribute 
names and values for the AOITT block are presented by an application program requesting a proxy cUent 
loutine to access a view, an AOUT proxy client setting a return view definition and creating an aflribute 
projgr object, and the application program requesting the AOUT proxy client to read out vahies for attributes 
named with granted privileges. The application program fonnats and displays the data. Displaygroup 
parameters aie part ofanI«>Wock definition and are. therefore, not configurable. Display groups are defined 
Ibrattribates. faf«™ation is advantageous^ updated while a PIO block is not 1^ 
and view groups control updating of non-linked PIO attributes associated with a btock. 

The process control environment 100 shown in FIGURE IC implements an overall strategy as if all 
connected devices are Fiddbus devices not only by the usage of a function block as a fundamental building 
block for control structures, but also by implementing an input/output architecture that beats Fiddbus and 
nonFieldbus devices in the same manner. The fundamental character of the input/output architecture is 
based on instrument signal tags QSTs) that furnish user-configurable names for all VO signals induding 
Fiddbus and nonFiddbus I/O signals. 

From the perspective of a user, an 1ST binds a user-ddined name to a signal type, to a spedfic signal 
iatbsVO subsystem, to a signal path including an attribute and to a set of signal property settings. 

ISTs are not installed in the manner of other system objects. Instead, signal properties inherent to 
20 the 1ST tag are combined with I/O Port and VO Device properties that are made available when an UO Card 
is instaUed. The combination of 1ST. VO Port and VO Device properties fiiroish information for creating a 
PIO function block in the run-time system The signal path from ISTs is included in the script that defines 
I/O Function Blocks during installation of a module. 
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To communicate throughout the process control environment 100. an I/O type Function Block uses 
an I/O reference definition. An 1ST satisfies the spedfication for an VO reference. Conventional VO 
devices, such as MTL devices supplied by Measurement Tedmdogies Umited of the United Kingdom, have 
an 1ST for eadi channel Hart and Fiddbus I/O devices may indude an 1ST for eadi distinct "I/O signal" on 
a Port or in a field Device. 1ST names have systcm-wide scope and share the name space of Modules. 
Devices, and Areas. In large systems. ISTs typically correspond to instrument signal names on 
instrumentation drawings. In small systems, formal instrument drawings may not exist so that no obvious 
1ST names arc infcned. Typically. ISTs are automaticaUy generated as cards arc configured based on a 
device hieiardiy path representing a controller node. VO subsystem, card and port so that aibitraiy 1ST 
names are avoided. TypicaUy most ISTs are created automatically when a new VO card is defined. For 
miiltipl&«igmil VO Oevkxs. an 1ST is automatically created for only a single "primary signal". In addition 
to automatic 1ST creation, a user may also create ISTs using an "Assign..." memi available ftom Uie 
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Explorer Node/IOsubsys/Port/Devioe tree with a Port or Device selected or using a "New..." memt available 
finm the Ejqiloier 1ST tree. 

ISTs have a "agnal Qrpc" property to ensure compatibiUqr between the 
Function B]iick(s) that accesses the VO signal. Signal type is one of: AIN, AOUT. DIN. DOUT. PON, 
PCOUr. ISTs have a set of "dgnal-rdateT attribntes specific to the signal type (e.g. EUO and EUlOO for a 
AIN. MOMENTARY or LATCHED for a DOirr. etc.). All signal sources with the same signal type have 
the same set of "signal attributes". AU other properties of the I/O subsystem objects are hcM in card, port, 
device attributes. 

Ptally oonfigored ISTs have a fiilly qpialified path to a corresponding signal in the I/O system. e.g. 
-CONl/IOl/S0yO01/FIELD_VAL-. An 1ST may be created without a defined path defined so that module 
configuration may be completed before I/O structure details are fiilly defined. Modules with I«) Function 
Blocks using ISTs with no defined path may be configured and installed but the run-tinie system must deal 
appropriately with missing I/O paths of missing ISTs on I/O Function blocks. A signal source has no more 
thanonelST. Attenqrts to configure more than one 1ST with the same path are rqectcd. 

A user may delete an 1ST. thereby deleting associated signal properties and possibly leaving some 
unresohrable 1ST references in I/O Function Blocks. A deleted 1ST does not affect card/^Km/device properties 
with a nonnal display of the 1ST on die Port/Device in the Ejqilorer tree indicating no associated 1ST. 

I/O-interfecc Function Blocks have at least one IST-Rcfercnce property. An IST-Reference property 
is either left blank to indicate that the function block does not connect to a 1ST. or is designated with a vaUd 
1ST name. An IST-Referencc property in an 1/0 Function Block is compatible with exacUy one 1ST signal 
type. For example, the IST-Rrfercnoe in the AI Function Blodc has an 1ST with a signal type "AIN" only. 
Sevaal I/O Fmurtion Blocks are conqntible with the same 1ST signal type. 

For compatibility with Fieldbus I/O Function Blodc definitions, Fieldbus VO Function Blodcs have 
attributes such as XD_SCALE. O0T_SCALE which overlap with some of the signal properties in ISTs. 
When a valid IST-Reference is made, the configured vahies of these overlapped Function Block attributes are 
ignored in the Run-time system and the corresponding properties from the 1ST are used instead. An engineer 
configuring Fieldbus VO Function Blodcs uses an indication of ignored attributes when a 1ST reference is in 
place. Suchanindicationistyiacaltypiesentedonadispl^asgrayedomandnoiMditabkte>awiA 
copied fiom the 1ST The I/O Ftoncthm Block holds a private setting lor the Ignored attributes which are 
typically downloaded and prottvtly overridden, if the IST-Reference is removed, the setting for these 
attributes retains utility. 

VO Cards, Ports and Devices arc incorporated into a configuration by a user operating a user 
intcrfece, either the Explorer™ or the Module Definition Editor. The channels on coirventional VO cards are 
called "pons" and treated as an I/O Port so that special case tenninology for conventional VO is avoided. 
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The user interface also aUows a user to delete UO Cards, Ports or Devices. Multiple I/O Card types are 
siqiported including, for example, 8-chan ^4TL AI, 8<han MTL AO, 8-chan MTL DI. 8-chan MTL DO, 4- 
dian NfTL Thermocouplc/RTD, 8-chan HART input, 8-chan HART output, and 4<hanSolcnoid. Some I/O 
Card types have a combination of I/O Port types on the same I/O Card. Deletion of an I/O Card deletes all 
subordinate Ports. Deletion of an I/O Port deletes all subordinate Devices. Deletion of I/O Ports or I/O 
Devices does not delete related instrument signal Ugs (ISTs). but the path of the 1ST path to the associated 
VO signal no longer is operable. If another VO Port or I/O Device is cieated which has the same path, the 
1ST autoroaacally refoinds to the I/O Port or I/O Device, so long as the signal type is compatible. 

A user can initiate the Install of an I/O subsystem, which installs or reinstalls alt I/O Cards defined 
in the Subsystem, The user can initiate the Install of a single I/O Card, which installs the card properties and 
all properties for subordinate I/O Ports and I/O Devices. 

The ExploierTM and the Module Definition Editor configure the I/O subs)fstem by aocesstqg current 
signal vahies, status, and selected properties that arc direcdy addressable as Attributes in the I/O subsystem. 
The user displays a graphic indicative of the current status of cards, ports, devices, and signal values and 
status by accessing the respective cards, ports, devices and signal values and status using device hieiarxiiy 
attribute path addressing (for example, -CONl/IOl/C01/P01/FIELD_VAL"). 

I/O subsystem attributes are communicated using the physical device path (for example, 
CONl/IOl/C01/P0I/D01/FIELD_VAL) for addressing in communications between devices. Communication 
of I/O subsystem attributes is advantageously used to transmit attributes from a controller/multiplexer 110 to 
a workstation 102, 104, 106 as shown in FIGURE IC for display and from a first to a second 
controller/multiplexer 110 for virtual I/O handling. 

Referring to FIGURE 16, a block diagram illustrates an organization of information for an 
instrument signal tag (1ST), An system 1ST table 1510 contains information relating to an 1ST including 
path information and pointers to a system object A first pointer 1512 designates a signal type which points 
to an attribute signal table 1520. A second pointer 1514 designates an entry in the attribute signal table 
1520. 

Accessing of information using device hierarchy attribute addressing advantageously allows system 
diagnostic displays to be designed and built for system integration checkout before Control Module work is 
complete. Device hierarchy attribute addressing also supports direct addressing of I/O signals from Modules, 
bypassing the use of I/O function blodcs and avoiding UO function block behavior. I/O Card, I/O Port and 
I/O Device identifiers are generally defined automatically according to slot position information and the like. 

Referring to FIGURE 17, a flow chart illustrates a method for bootstrap loading a control system 
throughout a network in the process control environment 100, including the operations of assigning the 
controller/ multiplexers 110 to a set of IP Addresses, a node name and other startup information that is not 
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Stored in flash ROMs of a controUer/ multiplexer 1 10. A piocess 1600 for assigning intanct protocol (IP) 
Addresses to a ControU^ upon its initial bootup includes the step of associating a MAC address in a Boot 
server, a Windows NT™ workstation, with a controller/ multiplexer name 1610. The MAC address alone 
designates the controller/ multiplexer identity. In step 1612, the nanns of the controller/multiplex^ is 
assigned an arbitrary device ro, and an ACN link nnmber and a PCN network numb^ 
the cable attadied to the controller/ multiplexer. In step 1614, an IP address of a device is calculated from 
the device ID, the ACN link nmnber and the PON network number. In st^ 1616, a UDP datagram, which 
designates defaMltpriinary and secondary IP addresses that are icscrred for b^ 

controller/ multiplexer MAC address in the UDP user data, is broadcast to a special UDP reserved boot port 
using the de&uhprirnary IP address for the source address on the primary interia^ In stq> 1618, the boot 
server matches the MAC address with the assigned name and IP addresses, and broadcasts the assigned name 
and IP addresses with an echo of the MAC address to the UDP boot port By broadcasting, the problem of 
doing any routing or ARP static entry manipulation is avoided In step 1620, the controller/ multiplexer 
receives the datagram, checks the MAC address, and if the MAC address matches, sets the IP addresses and 
saves the node name and device ID. If the datagram is not received, the procedure is rq)eated using the 
secondary interfece through the operation of branch step 1622. In step 1624, the controUer/ multiplexer, 
using the new address, sends a message to the boot server saying indicating that the controUer/ multiplexer is 
operational. 

In step 1626, a user enters a Device Name, Device MAC Address, ACN Link Number and PCN 
Network Number. The device ID can be automatically assigned by configuration software. The 
communications subsystem calculates the devices three IP addresses from the configured ACN Link number, 
PCN Network Number and the assigned device ID. In step 1628, controller/ multiplexer or I/O card software 
is flash downloaded over the ACN network by passing messages and S-Record files between devices on the 
ACN. 

Referring to FIGURE 18, an object communicatiQn diagram shows a method for creating a device 
connection for the active, originating side of a connectiort An appUcation program in either a workstation or 
a controUer/ multiplexer requests access to an attribute which is contained in another device. A UDP 
communications connection to the other device is established by the communication services so that the 
attribute can be accessed. Creation of a device connection spans two separate appUcation programs. The 
plication program which initiates the connection by requesting data located in another device and the 
Remote Object Comnumications (ROQ Services appUcation program that actuaUy sends the messages to the 
other device. If no connectian exists when the ROC Services process is ready to send a message to a device, 
the ROC services create a oormection to that device. 

Prior to creating the device connection, a device to be connected has a vaUd Device Table containing 
the source device, is operating and includes an object RtDeviceConnection which monitors messages m the 
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device oannection port After Che deiice coiiiia:don is created, a coimeccion is 

devices and an RlDeviceCoanection instance is created in the active device to handle the connection. 

In stq) 1710, an application program sends a message getContainer to object RtSite which returns 
the object ID of the module found or created, in step 1712, object RtSite sends a Locate message to object 
RtPlantArea which locates the nuMlule and return its object ID. In step 1714, object RtSite sends a 
.GetDevice message to object RtDevice which returns the object ID of the device containing the module. In 
step 1716, assuming that a proj^ for the remote device does not exist, object RtDevice sends a Cieate 
message to object RtDcvkeProxy. In step 1718, object RtDeviceProxy creates an instance of object 
RtDeviceProxy using template RtNew. In step 1720, oibjea RtDevicePro^ asks object 
RtDevlceConnection to G^eviceConnectlonlndex which returns the index of the device name in the 
device connection table managed by object RtDeviceConnection. In step 1722, object RtDeviceProi^ 
registers the pointer to the RtDeviceProxy instance for the connected device by sending a RegistctPointer 
message to the object RtRegistry and returns the device proxy Object ID to object RtDevice. In step 1724, 
object RtPlant4rca sends a Create message to object RtModuleFroxyClient to create a proxy client for the 
remote module. In step 1726, objea RtModuleFroxyClient sends a Create message to object 
RtModuleProxySenrer to create a proxy server for the module in the remote device. In step 1728, object 
RtModuleProxyServer builds a create proxy server message and asks <*ject RtRocReqRespService to 
SendReqaest to the remote device. In step 1730, object RtRocReqRespServicc Appends the message to the 
Outbound Message Queue for the ROC Communications Services process to send to the remote device. In 
step 1732, object RtRocReqRespService in the ROC Comm Services process issues a RemovcFirst 
command to the Outbound Message Queue and gets the create proxy server message. In step 1734, the 
RtRocReqRespService sends the message by issuing a sendMsg command to the aRtDeviceProxy instance 
for the destination device. In step 1736, the aRtDeviceProxy instance issues a GetDeviceConuection 
command to RtDeviceConnection to get the Object ID for the RtDeviceConncction instance for the 
destination device. Assuming that a device connection does not already exist, in step 1738, object 
RtDeviceConnection performs a createDeviceConnection. In step 1740, object RtDeviceConnection 
creates an instance of RtDeviceConnection using template RtNew. In step 1742, object 
RtDeviceConnection registers the pointer to the RtDeviceConnection instance by sending a 
RcgpsterPointer message to the object RtRegistry and returns the device connection Object ID to object 
RtDeviceConnection. In step 1744, object RtDeviceConiiection sends a startActiveConnection message to 
the aRtDeviccConncction instance. The aRtDeviceConnection instance performs the neoessaiy steps to 
establish the connection to the other device. Inst^ 1746, the RtDeviceProxy instance issues a sendMsg to 
the aRtDeviceConnection instance to send the create server message to the remote device. In step 1748, the 
aRtDeviceConnection instance sends the message to the remote device over the newly created connection. 

Referdng to FIGURE 19, an object communication diagram shows a method for creating a device 
connection for the passive, listening side of a connection. A request to establish a device connection is 
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noceived from another workstation or conlroUer/ multiplexer. The comnnmications services establishes a 
UDP communications connection with the requesting device. 

Previous to creation of the connection, a device to be connected to is operating and contains an 
object aRtDeviceConnection which is ready to establish a connectioa Objea RtDevice Coiinection exists in 
the device and is listening for input messages in the form of a sync request After the connection is created, a 
connectionis established between thetwodevicesand an WDeviceConaection instance is created in the 
passive device to handle the ooimection. 

In step 1810, objea RtDeviceOnmection receives a sync request message from a remote device. In 
step 1812, object RtDeviceCiRuiectioa sends a Create message to object RtDeviceConnection to create a 
connection to the requesting device. Assuming that a device connection does not already exist, object 
RtDeviceConnectiaa performs a createDevkeConnection in step 1814. In stq> 1816, object 
RtDcviceConnectioa creates an instance of RtDevkcConnectioa using tenqdate RtNew. In stqi 1818. 
object RtDeviceConnection registers the points to die RtDeviceConaectioa instance by sending a 
RegisterPointer message to the RtRegistry and returns the device connection object ID to object 
RlDeviceConnection. In step 1820. object RtDeviceConnection sends a Create message to olgect 
RtDevlceProxy to create a device proxy for the requesting device. In step 1822, object RtDeviceProxy 
creates an instance of RtDeviceProiy using template RtNew. In step 1824, object RtDeviceProxy sends a 
GetDeviceConnectionlndex message to the object RtDeviceConnection to have the index of the device in 
the device connection table managed by RtDeviceConnection for later use. In stqi 1826, object 
RtDevicePnny registers the pointer to the RtDeviceProxy instance by sending a RegisterPointer message 
to the RtRe^try and returns the device |m)xy object ID to RtDeviceConnection. In step 1828. object 
RtDeviceConnection passes die sync request message to the aRtDeviccConnection instance for processing 
via the handlelnboandMessage method. In step 1830. object aRtDeviccConnection sends a sync response 
message back to the remote device to indicate successful completion of the Device Connection creation. 

Refening to FIGURE 20, an object communication diagram iUustrates a method for sending 
request/ response messages between devices. The remote objea communications (ROO service in one device 
sends a request message to the ROC service in another device. The request message is processed and a 
reqwnse niessage is sent bade to the originating device. 

Prior to sending messages, a UDP device connection is established between devices. Following the 

sending of request/ response messages between devices, a response message from a remote dew 
recdved and is ready for processing ROC services. 

In stqi 1910, a read attribute request is issued by an applkation program to an aRtDeviccPro^ 
iiistance associated wiUi a remote device. In step 1912, the aRtDeviceProiy instance bo^ 
message to be sem to the remote device to read Uie attiftute vahie and asks the RtRocReqRi^^ 
send tiie message using die SendReqnest medwd. In step 1914. olgect RtRocReqReqiSerTice sends the 
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message to the instance of RtDcviceConnection associated with the connection to the remote device using 
the scnd.BUg method In stq> 1916, the instance of RtDcviccConncctioD then transmits the message to the 
remote device over the device connection. In step 1918, the instance of RtDeviceConnection in the remote 
device receives the message and requests the RtRocRooter class to route the message to the correct inbound 
message service. In step 1920, object RtRocRouter determines that the message is a request/response 
message and requests object RtRocReqReapService to ProcessInboundReqResp. After the message is 
processed by the ROC services and the message consumer a response message is built, in step 1922 object 
RtRocRqstRespService sends the response message to the originating device using the SendResponse 
nuthod. In step 1924, the outbound message queue processing of RtRocReqRespScrvice sends the response 
message to the instance of RtDeviceConnection associated with the connection to the source device using the 
send_msg method. In sisp 1926, the instance of RtDeviceCoDncction then transmits the response message 
bade to the original device. In step 1928, the instance of RtDeviceConnection in the original device receives 
the message and requests the RtRocRoater class to rontc the message to the correct inbound message 
service. In step 1930, object RtRocRoater determines that the message is a request/response message and 
requests RtRocReqRespScrvice to ProccssinboandReqResp. 

Referring to FIGURE 21 an object communication diagram Ulustratcs a method downloading a 
network configuration. A user, following completion of the device configuration for a system, initiates a 
download to a controUei/ multiplexer, A device table configuration script is built by the configuration 
plication. Using communications services , the configuration application establishes a device connection 
with the controller/ multiplexer to receive the download and sends a download script to the controller device. 
The controller/ nmltq)lexer receives the download script messages and processes the device table. In step 
2010, a configuration download application program builds remote object communications (ROC) script 
download messages containing the device table download script. In step 2012. the Download q)plication 
issues a GetDcvicc message to RtDevice to get the Object ID for the RtDeviceProxy for the remote device. 
In step 2014, the RtDeviceProxy docs not yet exist so a Create message is sent to RtDevicePnixyC to create 
the necessary device proxy object In step 2016, RtDeviceProxyC sends a GetDeviccConnlndex message to 
RtDeviceConnection to get the index of the device connection for the remote device in the device 
connection table. In step 2018, the device connection does not yet exist so aRtDeviceConnection object is 
OTcated to manage the connection to the remote device, A lookup is performed in the database to find the 
remote device entry. The device communications data (for example, ID and IP Addresses) is retrieved &om 
the database and a new entry is added to the configuration devices connection table. Thisconnecfionis 
marked permanent in the connection table since the device initiated the connection. In step 2020, a 
startActiveConncction message is sent to the aRtDeviceConnection object to establish a connection to the 
remote device. In step 2022, the aRtDeviceConnection sends an RtSyncMcssage to the remote device. In 
step 2024, the remote device receives the RtSyncMcssage and attenqits to find an entry in the device 
connection table for the sending device. In step 2026, no entry is found so a new eatxy is added to the device 
connection table for the sending device and aRtDeviceConnection object is created to handle the connection 
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in the reodving device. In step 2028, a RtSyncRqilyMessage is oeatcd and sent bade to the sending device 
containing the device connection index from the device table. The device connection is now established and 
xeady to send and lecdve messages. In step 2030, the RtDeviceProxy C sends a create RtDeviceProxyS 
message to the remote device. In stq> 2032, the RtDeviceProxyS is created in the remote device. In step 
2034, the Download Application sends the download scripts to the remote device via 
RtRocReqRespScrvices using the SendMsg call In step 2036, RtCommScriptDownload receives the 
Device Table script and processes each device table item and stores the data in a database Registry used to 
hold configuration data. For controller/ muhtplexers this processing is used to create RiDeviceConnection 
objects and add the objects to the device connection table;, allowing the memocy to be acquired on download 
rather than siAsequcntly. 

The digital coiurol system program 115 includes a diagnostic program and display routine for 
viewing diagnostic information relating to a process in a coherent manner, whether the diagnostic 
information is derived from a Fieldbos device or a nonPieldbus device. The digital control system program 
115 advantageously incorporates <fiagnostic information relating to all devices within the process control 
environment 100 and presents this information to a user in a uniform manner using the diagnostic display 
routine so that the control strategy and the diagnostic information are presented to a user as if all control 
actions and diagnostic information were performed or g^erated at a single location 

Referring to FIGURE 22, a pictorial view of a £ront-of-screen display illustrates a flowchart of the 
operations of a diagnostic display routine 2200 including a communication diagnostics program 2210. A 
user grq)hicall)r views the status and integrity of workstations, controllers and network links within the 
process control environmem 100 using easily-recognized icons. The diagnostic display routine 2200 also 
generates sumraaiy status information for a device or networic link segment The diagnostic display routine 
2200 displays detailed internal integrity information concerning devices connected to the network, including 
packets sent and received, the number of connections and the like. Some diagnostic information is accessed 
via modem to inclement rmote diagnostics foncdonality. 

A workstation 102 or 104 and controller/ rrmltiplexer 110 function in combination to supply detailed 
diagnostic information about the status of the communications subsystem in connected devices including 
detailed integrity information aboxit the status of the ACN cormnunications links, device connections, 
ethemet statistics, and communications stack diagnostic information. A diagnostic check of communication 
fonctionali^ is also supported. The communication diagnostics 2210 support three levels of diagnostics 
information including basic diagnostics for the entire network, diagnostic information for a single device and 
diagnostic information for a angle device cormectiort 

At the basic network diagnostic level, the conmumication diagnostics 2210 gather information from 
all network devices and present the information to a user. The communication diagnostics 2210 collect 
information from remote controller/multiplexers 110 on demand or as a badcground task ocecuting 
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periodicaUy. The communication diagnostics 2210 send network commimications status requests to a 
diagnose port of a particular device to determine integri^ of the communications path to that device. 

A refuse to a nctwoik communications status request contains comnmnications integri^ 
information including device type information indicative of whether the device is a controller or woricstation, 
and primaiy and secondaiy status summary informatioa The Connection Status Siumnaiy, which is set to 
'^ad'* if an error exists on the link, is added as an attribute to a Communications StAsystem Module, 
allowing a user to display these values on the <^rator interface upon request 

The commnnication diagnostics 2210 request diagnostic information from each device connected 
into the process control environment 100 so that the status of the conununications links between the device 
and a remote device are displ^ed. 

The communications diagnostics 2210 monitor and display diagnostic information for a single 
device to supply detailed diagnostic information about comnmnications for a particular device, including link 
status information for device connections and the ethemet statistics for ethemet interfaces in the device. The 
communications diagnostics 2210 request the device commimications status using an appropriate diagnostic 
remote objea communications (ROC) message. The device communications status includes information such 
as a Device Table Index, a Device ED, a Device Connection State (Ready, Synching, ACK Pending, Closed), 
a Primary Device Address, a Secondaiy Device Address, a Link Status and diagnostic information for a 
single device connection. 

Ethemet statistical information is held in counters which start counting when the device is booted 
and are not reset until reboot of the device. The counts are implemented as attributes to the Communications 
subsystem module as part of the module attributes and include input error information including numbers of 
total input errors, iiqxit CRC errors and input ovenun errors. Output error information includes nimibers of 
total output errors, output late collisions, output collisions exceeding a preselected number, output ovenun 
errors and output carrier lost errors. Other counts include the numbers of pac^kets recdved, packets sent, 
bytes received, bytes sent, broadcast packets received, broadcast padcets sent, unknovim protocol messages 
received, transmit deferrals, ^ngle collision transmits and multiple collision transmits. 

The comnmnications diagnostics 2210 also monitor and display detailed diagnostic information for 
a partiailar device connection in a particular device. When a user requests device connection statistics, the 
communications diagnostics 2210 designate a destination device ID for a connection. Device coimection 
statistics contain link status information and statistical infoimation for the designated device coimection, 
including a Device Connection State (Ready, Synching, ACK Pending, Closed), a Remote Primaiy Address 
(Primary ACN IP Address for the destination device), a Remote Secondaiy Address (Secondaiy ACN IP 
Address for this device or 0). a Primary Link Status (Good/BacQ, a Secondaiy Link Status (Good/Bad). The 
statistics also include counts of messages received on Primaiy link, messages recdved on Secondaiy Link, 



wo 980035 



PCT/US98/01573 



messages sent on Primaiy Link, messages sent on Secondaiy Link, Synchs Sent, Synchs Received, ACK 
Time-outs on Primaiy Link, and ACK Time-outs on Secondaiy Link. 

The communications diagnostics 2210 support checking of a communications path between two 
devices in a network. A first device sends a message, such as an evoking message, over a specified 
5 comiminication link to a remote device. The remote device echoes the message back to the sender. A 

sucoessfol evoking message and echo are indicative that the communications subsystem is functional in the 
rdnote device. This interaction is different from a normal TCP/IP ping which is handled coi^ 
cdiecnet hardware driver. 

Referring to FIGURE 23^ an object oommunication diagram illustrates a method for one device to 
10 check whether another device exists on a network. A diagnostic application program which is either part of 
the process control environment or a stand-alone application monitors to determine whether a remote device 
exists on an ACN netwoik and, if so, idiether the remote device is capable of communication. The 
diagnostic application program sends a message to the remote device and expects to receive the message 
echoed from the remote device or a time-out 

15 In step 2310, a diagnostic application program sends a Ping message to object RtCommDiag 

requesting that a communication inquiry (ping) be performed to a specified device name or address. In st^ 
2312, object RtCommDiag oeates a communications sodcet to perform the inquiiy. In sstisp 2314, object 
RtCommDiag creates an RtEchoMcssage to send to the remote device. In stq> 2316, object RtCommDiag 
sends the RtEchoMessagc to the specified device using RtCommSendTo and waits for the message to be 

20 echoed back from the remote device, in step 2318, object RtDeviceConncction in the remote device receives 
the RtEchoMcssage and processes the message using the HandleDiagaosttcMessage method In step 2320, 
object RtDeviceConncction immediately returns an RtEchoMcssage with a diag code of echo response to 
objea RtCommDiag in the source device using RtCommSentToMessage. In step 2322, objea 
RtCommDiag receives the echo response message and returns a successfiil status to the diagnostic 

25 plication. If no response is received from the remote device, in step 2324, object RtCommDiag returns a 
fidled status to the diagnostic application. In step 2326, object RtCommDiag closes the socket created to 
perform the inquiiy. 

Referring to FIGURE 24, an object communication diagram illtistrates a method for requesting 
device communications diagnostics. A diagnostic application program requests, accesses and displays the 
30 status of all device connections in a remote device. The diagnostic application program saids a request for 
the required diagnostic information to the remote device and waits for a response. Once the response is 
recdved, all device connections and device status in the remote device are displayed to the user. This 
information may be communicated in multiple messages so that the diagnostic appUcadon program makes 
muttqile requests for diagnostic data. 
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in step 2410, a Diagnostic i^piicatioa piogiam sends a GetDeviceCommDiags request to object 
RtCommDiag to request communications diagnostics for tlic device connections in tiie remote device. In step 
2412, object RtCommDiag sends a GetDeviceConnectionlndex message to object RtDeviceConnection to 
request the device connection table index for tlic remote device. In step 2414, object RtCommDiag issues a 
Create to object RtRocMessage to create a message to be used to request diagnostic information. In step 
2416, object RtRocMessage creates a new instance of aRtRocMessage to be used for the diagnostic request 
In step 24IS. object RtCommDiag builds the message to be sent and issues a SendReqnest to 
RtRocReqRespService to said the message to the remote device. In step 2420, object RtCommDiag issues a 
waitForResponse to the aRiRocMcssage instance created for the diagnostic request message. In step 2422. 
ol^ect RtRocReqRespServkc performs a send_msg on the instance of aRtDeviceConnfiction associated 
with the remote device. In stqp 2424, the aRtDeviceConnection instance transmits the request message to 
the remote device. In step 2426, objea RtDeviceConnectioii m the remote device receives the message and 
issues a handlelnboundMessage to the aRtDeviceConnection instance associated with the sending device. 
In step 2428, the aRtDeviceConnection instance passes the message ofif to RtRocRouter via the Route 
method for processing. In step 2430. object RtRocRouter responds to the message by issuing a 
ProcessInboundReqResp to the RtRocReqRespSenice. In step 2432, the RtRocReqRespService 
determines the message type ftom the request message ID and issues a perform command on the 
RtRocDevConDiagListMsg message. In step 2434, RtRocDevConDiagListMsg sends a GetDiagUst 
message to object RtDeviceConnection to get the device connection diagnostic data for the device 
connections in this device. In step 2436, object RtDeviceConnection puts the diagnostic data into a data 
buflfer using various fill routines provided by the utility class RtDevConDiagUstData. In step 2438, 
RtRocDevConDiagListMsg then performs a CreateResponse to create the response message containing the 
diagnostic data. In step 2440, RtRocDevCdnDiagListMsg issues a storeOn message to 
RtDevConDiagListData to put the diagnostic data into the re^nse message. In step 2442, 
RtRocDevConDiagUstMsg sends the req)onse message back to the requesting device through 
RtRocReqRespService using the SendResponse method In step 2444, RtRocReqRespService performs a 
scnd_msg to the aRtDeviceConnection instance associated with the requesting device. In step 2446, the 
aRtDeviceConnection instance transmits the response message bade to the requesting device. In step 2448, 
the aRtDeviceConnection instance in the requesting device receives the response message from 
RtDeviceConnection via a handlelnboundMessage. The response message is then send to RtRocRouter 
using the Route method. In step 2450, RtRocRouter performs a ProcesslnboundReqResp on 
RtRocReqRespService. In step 2452, RtRocReqRespService informs the aRtRocMessage instance that the 
response to the original request for diagnostic data is available. In step 2454, RtCommDiag issues a 
readFrom to RtDevConDiagListData to retrieve the diagnostic data from the response message. In step 
2456, RtCommDiag passes the data back to the Diagnostic implication which issues getData messages to 
RtDevConDiagUstData to retrieve the diagnostic data for display. The requesting device returns a buffer 
containing the general diagnostics for ail device connections actively in place. 
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Referring to FIGURE 25, an object communicatioii diagram illustrates a method for lequcstiiig 
device comiection communications diagnostics. A diagnostic application program requests, accesses and 
displays the detaUed status of a single device connection existing in a remote device. The diagnostic 
application program sends a request for device connection statistics information to the remote device and 
waits for a response. Once the response is received, the device connection statistics for the device connection 
arc displaiyed to the user. In st^ 2510, a Diagnostic Application program sends a GetDeviceConDiags 
request to RtCommDiag to get the device connection statistics for a specific device connection in the remote 
device. In &ep 2512, RtCommDiag sends a GetDeviceConnecttonliidGx message to RtDeviceConnection 
to get the device connection table index for the remote device. In step 2514, RtCommDiag issues a Create to 
RtRocMcssage to create a message to be used to request the diagnostic information. In step 25^ 
RtRocMcssage creates a new instance of aRCRocMessage to be used for the diagnostic request In step 25 18, 
RtCommDUg builds the message to be sent and issues a SendReqnest to RtRocReqRespScrviee to send the 
message to the remote device. In step 2520, RtCommDiag issues a wattForResponse to the aRtRocMessage 
instance created for the diagnostic request message. In st£^ 2522, RtRocRcqRespService performs a 
send^msg on the instance of aRtDeviceConnection associated with the remote device. In step 2524, the 
aRtDeviceConnection instance transmits the request message to the remote device. In step 2526, 
RlDeviceConnection in the remote device receives the message and issues a handlelnboundMessage to the 
aRtDeviceConnection instance associated with the sending device. In step 2528, the aRtDeviceConnection 
instance passes the message to RtRocRouter via the Route method for processing. In step 2530, 
RtRocRouter determines that the message is a request response type message and issues a 
ProcessInboundReqResp to the RtRocReqRespService. In step 2532, the RtRocRcqRespService 
determines the message type from the request message ID and issues a perform command on the 
RtRocDevConDiagDetailMsg message. In step 2534, RtRocDevConDiagDetailMsg sends a 
GetDiagDetaii message to RtDeviceConnectioii to get the device connection statistics for the requested 
device connection. In step 2536, RtDeviceConnection puts the diagnostic data into a data buffer using 
various fill routines provided by the utility class RtDevConDiagDetailData. In step 2538. 
RtRocDevConDiagDetailMsg performs a CreateResponse to create the response message containing the 
diagnostic data. In step 2540, RtRocDevConDiagDetailMsg issues a storeOn message to 
RtDevConDiagDetailData to put the diagnostic data into the response message. In step 2542, 
RtRocDevConDiagDetailMsg sends the response message back to the requesting device through 
RtRocReqRespService using the SendResponse meUiod. In step 2544, RtRocReqRespService performs a 
send.msg to die aRtDeviceConnectiim instance associated with tiie requesting device. In step 2546, the 
aRtDeviceConnection instance transmits the response message back to the requesting device. In step 2548, 
the aRtDeviceConnection instance in the requesting device receives the response message ftom 
RtDeviceConncctimi via a h a ndlelnh mmdMessage. The response message is sent to RtRocRoater using 
the Route method. In step 2550, RtRocRouter perfonns a ProcessInboandReqResp on 
RtRocReqRespService. In step 2552, RtRocReqRespService infimns the aRtRocMessage instance that the 
leqxmse to die original request for diagnostic data is available. In stq) 2554, RtCommDiag issues a 
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readFrmn to RtDcvConOiagDetailData to retrieve the diagnostic data fiom the response message. In step 
2556, RtConunDiag passes the data back to the Diagnostic AppUcation which issues getData messages to 
RtDevConDiagDetailData to retrieve the diagnostic dau for diqtUy. 

GeneraUjr, a contioUer/ mnltiplexer 1 10 is manual^ added to a network. For exanqile. a device is 
tjpicalljr added to a network when a user selects the ACN Segment onto which the device is to be connected 
and issues a 'New Device* command. The user is prompted for the device type, either worksl^on or 
coBbDUei/ multiplexer, the device name and a comment fidd. A configuration system automaticaUy assigns 
the next Device m to the device and builds a dcfimtt name based on the Device ID. Optional^, the 
configuration system automatically generates primaiy and secondary IP addresses and sidmet masks for the 
device based on PCN number and the previously assigned Device ID. 

Alternatively, a comroller/ muhvlexer is automatically sensed and incorporated into a run-time 
system as shown in nCDKE 26. In step 2610, a controller/ multiplexer, upon connection to the ACN and 
apiflicatiDnrf power, automatically sends a request for identification or verily IP address assigm The 
request message includes the MAC address of the controller/ mnltiplexer. The request is handled by a 
"Plug&Pl^ Network Configuration Service", which is known in the operating system art. at a master 
configuration controUcr/ multiplexer in step U12. In step 2614. the "Plug&Play Network Configuration 
Service" receives the request from the network to assign/ verify an IP address, searches a table of configured 
devices for a MAC address match. If a match is found, in step 2616 the ''Plug&Play Network Configuration 
Service- responds widi the Device Name, Device ID. IP Address Information, Subnet Mask Information, 
ACN Segmratt Number and other items included in the Device Table. If no match is found, in step 2618 the 
"Plug&Play Network Configuration Service" automatically generates a de&ult name for the device based on 
the oonttoUei/ mnlt^exer MAC address (for example. ContrDller-000001). The new device is added to the 
database in a Device Scratch area in stq> 2620. 

In step 2622. using the ExplorerTw a user selects each unassigned controllei/ multiplexer in the 
Device Scratch area, drags the sdection to the appropriate ACN segment and. and either adds the selection to 
the qrstem as a new device or drops tiic selection to a pre-existing device configuration. If the unassigned 
coatroUei/ mnltqdexer is added as a new device, the configuration processing proceeds in Uic manner of 
manual incorporation of the device. In step 2624, a user is prompted for the real device name using the 
previously asagned name ♦Comrdler-OOOOOr as a de&ulL If automatic address assignment is set. the new 
device is assigned the next Device ID and associated IP addresses and Subnet masks are antomaticaUy 
assigned in s^ 2626. Ifmannal address assignmem is set. the device is automatically assigned the next 
Device ID and the user is prompted to enter the IP Addresses and Subnet Masks in stq) 2628. TheMAC 
address for the conlroUer/ multiplexer is set to the MAC address of the 'ContrDller-OOGOO 1' as dragged into 
the ACN sclent The new controller/ multiplexer Name. Device ID, IP Address, Subnet Ma^ and ACN 
nnmbcr are added to the device table in the database. The next request by an unconfigured controller/ 
nufltiplcxer is answered by the "Plug&Play Network Configuration Service". 
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If a new controUer/ multiplexer is dragged and dropped over an existing device, that device most be 
a controUer/ multiplexer type device and have an unassigned MAC address. Accordingly, the MAC address 
of the previously ent«ed controUer/ multiplexer is set to the MAC address of the *ControUcr-OOOOOr device 
which was dropped. The new controUeiy multiplexer Name, Device ED, IP Addresses. Subnet Masks and 
ACN mxnaba are available for sending to the requesting controUer/ multiplexer by Uic Tlug&PI^ Network 
Configuration Senice". 

The digital control system program 115 includes an auto-configure routine for automatically 
configuring the input/output (I/O) subsystem in response either to an "anloKxrafigure" command fcy a user or 
in response to detection of a new controUea[/multiplexer. 

Rfifcning to FIGURE 27, a flow chart iUustrates steps of an automatic configuration routine for 
configuring a physical I/O device. An auto<onfigure command may be directed to a ContioUca/^ 
1 10. causing each UO subsystem in the ControUer/Multiplexer 110 to autosxmfigurc. An autoKxmfigure 
command may be directed to an I/O subsystem, causing each I/O Card in the I/O sid)system to auto- 
configure. An auto-configurc command may also be directed to an I/O Card. 

The auto-configure operation for an I/O Card first interrogates the I/O Card at a particular card 
position to detennine a Card Type in step 2710 and. in^lidtiy fi)r some I/O Cards, tiie number of I/O Ports in 
the DO Card If no I/O Card is previously created in tiic engineering databM 

Card of tile appropriate type is defined and the ^ropriate number of I/O Ports are created in step 2712. If 
an I/O Card does exist in tiie engineering database for tiiat card position, but tiu; Card Type in the 
engineering database does not match tiie Card Type sensed at tiic card position, tiic auto-configure operation 
generates a graphic notification of tiic mismatch in stq> 2714 and interrogates a user to detennine whetiier 
tiie engineering database is to be changed to include tiie sensed Card Type, The Card Type in tiie engineating 
database is changed to tiie sensed Card Type in step 2716 if requested by tiie user. 



tm 



Once the Card Type is known, the auto-configuration program intenogates each I/O Port i 
accordance witii tiie Card Type in stsp 2718 to determine the Port Type and. if information is available, tiie 
nmnbcr of I/O Devices on the I/O Port, If no I/O Port is previously created in tiie engineering database for 
tiiat port address, an I/O Port of tiic ^jpropriate type is defined and tiie appropriate number of I/O Devices 
arc created in step 2720. If an I/O Port exists in tiie engineering database for tiie Port address, but tiie Port 
Type does nm match tiie type of tiie sensed yo Port, tiie user is notified of tiie mismatch in ste^ 
asked wh^^er tiie engineering database is to be dianged to match the sensed UO Port in step 2724. The Port 
T>pe in tiic engineering database is diangcd to tiie sensed Port 



J user. 



^in 



Once the Port Type is known, the auto-configiuation program intenogates each I/O Device i 
accordance witii tiie Port in step 2728 to detennine tiie Device Type. If no I/O Device is picvioosly 
created in tiic engineering database for tiiat device address, an I/O Device of tiw 
instcp2730. If an I/O Device exists in tiie engineering database for tiie Device address, but tiie D^ 
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Type docs not match the type of the sensed I/O Device, the user is notified of the nusmatch in step 2732, and 
asked whether the engineering database is to be changed to match the sensed I/O Device in step 2734. The 
Device Type in the engineeri^g database is changed to the sensed Device Type in step 2736 if requested by 
the user. 

In step 2738, instrument signal tags (ISTs) arc automatically created for primary signal sources on 
the I/O Ports and I/O Devices, unless an 1ST already exists with the identical signal source path. 

Referring to FIGURE 28. a front-of-scrccn display, also called a "screen" 2800, for a graphical user 
interface (GUI) depicts a display of a system configuratioa The screen 2800 depicts navigation selections 
which are operated by a user to select, construct and operate a process control configuratioa The navigation 
program siqiplies an initial state for navigating across various tools and processors in a networic A user 
controk tiie navigation program to access Mbraries, areas, process control equipment and security operations. 

The illustrative system configuratioa is described and controlled with respect to a control system 
setup 2802, control strategies 2804, and a physical setup 2806. The ftmctions of automaticaUy sensing and 
automaticaUy configuring a control system relate to the physical setup 2806. In particular, the functions of 
automatically sensing and automatically configuring physical devices in a control system relate to die 
commission and activation of devices in the control network 2808. and the decommissioning of controUers 
2810. 

In an illustrative embodiment, a process conUol system controls various devices attached to a 
process control network in accordance with a Fieldbus standard protocol. In the Fieldbus protocol, a standard 
user application is defined based on blocks. A block is a representation of various different types of 
application functions. Types of Modes include resource blocks, fiinction blocks, and transducer blocks, 

A resource blodc describes characteristics of a fieldbus device such as a device name, manufacturer, 
and serial number. A device includes only a single resource block. 

A function block defines tiie control system behavior. Input and output parameters of fimction 
blodcs may be linked over the fieldbus. The execution ofeach fimction block is precisely scheduled. Auser 
application may inchide numerous fimction blocks. Examples of standard fimction blocks indudc analog 
inpai (AI), analog output (AO), bias (B). Control Selector (CS), Discrete Irqmt (Dl), Discrete Ou^ut (DO), 
Manual Loader (ML), Proportional/ Derivative (PD), Proportional/ Integral/ Derivative (PID) and ratio (RA). 
Function blocks are built into fiddbus devices to define a sdectcd device fimctiona^ In one example, a 
sinq)le temperature transmitter may contain an AI fimction block. A control valve often includes a PID 
function block and an AO block. 



A transducer block dccoiq>les fimction blocks firom local input and output fimctions for reading 
sensors and commanding output hardware. Transducer blocks contain information such as calibration dau 
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and sensor type. TVpically a user applicatioa uses one transducer block for each inimt or output function 
blodL 

Another object defined in the user ^cation includes link objects for defining the links between 
fundion block inputs and outputs inteinal to the device and across the fieldbus network. Trend objects allow 
local trending of function blodtpaiamrtets for access by other devices. Aleit objects are used to allow 
reporting of alarms and events on the fieldbus. View objects are predefined groupings of block parameter 

s«rts that are used in the human/ machine inlerfeoe. The fimction Mock specification defines four views for 
each type of blode 

Refiaiing to FIGDRE 29, a state transitijm diagram ilhistrates the various m 
The fieU device states mdude an oflEKne state 29(12. an muecognized state 29(M. a stan^ 
commissioned state 2908, and an unbound state 2910. The state ofafieW device is detennined by several 
parameters including a system management state (SM-Stale). a pl^sical device tag (PD-Tag). a device 
address, device revision information (Rev*), and a device identification (Device-ID), bi the ilhistralive 
embodiment, a device in the commissioned state 2908 is a Fieldbus device that is available for control 
strategy configuration and installation. A deoommissionBd device is a device that has been removed fhim the 
commissioned stale 2908. 

Several events occur that gouxate a state transition of a plurality of state transitions Tl through 
T14. One or more actions are performed during each state transition. 

A state transition Tl is caused by the event in which a field device residing at a temporary address is 
queried with a system management identify service (SM-IDENTIFY) and the query determines that the 
device has a deared physical device tag. The state transition Tl changes from a NUIi state to an OFFLI>fE 
state by allocating a standby address for the fieUl device. Executing logic, typically in the form of firmware, 
software, or hardware, executes a set plgrsical device tag service (SET-PD-TAQ to set the plgrsical device tag 
identical to the device identification of the field device. Executing logic also uses a set device address service 
(SET-ADDRESS) to send a standby address to the fidd device. 

A state transition T2 is caused by the event in which a fidd device residing at a temporary address is 
queried with a system management identify service (SM-IDENTIFY) and the query determines that the 
device has a physical deWce tag that Is Idemical to the device identification of the device. The state transition 
T2 changes fhra a WLL state to an OFFUrffi state ly allocatfag a standby a* 
Executing logic uses a set device address service (SET-ADDRESS) to send a standby address to the field 
device. 

A state transition T3 is caused by the event in which a field device residing at a temporary address is 
queried with a syston management Identify service (SM-EDENTIFY) and the quay detennines that the 
device has a physical device tag and a device identification configured for the current process control system 
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netwofkUnk. The suie tninsiUon T3 changes fiom a NUli s^^^ 

Uiat employs the set device address seivicc (SET-ADDRESS) to send an assigned address to the field device. 

A state transition T4 is caused by the event in which a field device residing at a temporary address is 
queried with a system management identify service (SM-IDENTIFY) and the query determines that the 
device has a physical device tag and a device identification not configured for the current process control 
system network Unk. TTic state transition T4 changes from a hrtJU, state to an UNRECOGNra 

A state transition T5 is caused by an event i n which the device appears at a temporary address and 
the device is being commissioned by a user The state transiUon T5 changes from an OFFLINE state to an 
OFFLINE state using executing logic, typically in the form of Gnawaic, software, or hardware, that executes 
a set physical device tag service (SET-PD-TAG) to clear the physical device tag of the field device. 
Executing logic also executes a set physical device tag service (SET-PD-TAG) to send an assigned pl^ical 
device tag to the field device. Executing logic further uses a set device address service (SET-ADDRESS) to 
send an assigned address to the field device. 

A state transition T6 is caused by an event in which the device appears at a temporary address and 
the device is being decommissioned by a user. The state transition T6 changes from an OFFLINE state to an 
OFFLINE state using executing logic that executes a set physical device tag seivicc (SET-PD-TAG) to clear 
the physical device tag of the field device. 

A state transition T7 is caused by an event in which a user requests to place a decommissioned 
device in standby. The state transition T7 changes from an OFFLINE sUte to an OFFLINE state by allocating 
a standby address for the field device. Executing logic executes a set physical device tag service (SET-PD- 
TAG) to set the physical device tag identical to the device identification of the field device. Executing logic 
also uses a set device address service (SET-ADDRESS) to send a standby address to the field device. 

A state transition T8 is caused by an event in which the field device appears at the standby address. 
The state transition T8 changes from an OFFLINE state to a STANDBY state through executing logic that 
reads device revision information from the resource block. 

A state transition T9 is caused by an cvoit in which the field device appears at the assigned address. 
The state transition T9 changes from an OFFLINE state to a COMNflSSIONED. 

A state transition Tl 0 is caused by a user requesting to commission a device in the STANDBY state. 
The state transition TIO changes from the STANDBY state to the OFFLINE state through executing logic 
that uses a dear address service (CLEAR-ADDRESS) to clear the device address. 

A state transition Tl 1 is caused by a user requesting to decommission a device in the STANDBY 
state. ThestatctranationTIlchan^fiomthcSTANDBYstatctothcOFFLINEstatcthro 
logic that uses a dear address service (CLEAR-ADDRESS) to dear the device address. 
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A state tiaimtion T12 is caused ^ a user reqnesdng to decommis^ 
C»MMISSIONED state. The state tian^tion T12 changes from the COMMISSIONED state to the 
OFPLINE state through executing logic that uses a clear address service (CLEAR-ADDRESS) to dear the 

device address. 

A state tiansitionTn is caused a user requesting to decoiniiussion a device 
state of the Fiddl«B system inan^geinem states. The state 11^ 

UNRECOGNIZED state to theOm.INBs.atethroughexecutingU,gict^ 
semce (SET-PD-TAG) to clear the physical device tag of the field device. 

A state transition T14 is caused by a nsei requesting to decommission a device in the SM- 
QPERATIONAL state of the Fiddbus system management states. The state tnmsitionT14 changes from the 
UNRECOGNIZED state to tbeOFFLINEstatethroughexecuting logic that 
(CLEAR-ADDRESS) to clear the device address. 

In accordance wth the Fiddbus standard. ,0 operate properly a Fiddbus device has a uniqm^ 
addKss(net^ricaddress)andauniquephysicaldevicetag. Each device connected to the process control 
systemnetworiclinkhasanniquenodedesignator. A data link spedfication specifies a range of allo«^le 
vataes for node designators indudiflg a nmge for permanent devices, a range for temporanr addresses, and a 
cangeforvisitordevices. The temporary addresses are used by devices that are not presently in the SM- 
OPERATIONALstata The Fiddbnsinterfece maintains partitioning of the address space for pennanent 
devices into three sets. One set. called "assigned addresses". i«dudes addresses assigned to devices ^th a 
spedfic physical device tag. regardless of whether the deWce is present on the bus. TT.e assigns 
assigned using a solhvare engineering tool on the basis of information input by a user rdating to Unk- 
Active-Scheduler takeover preference. A second set. tenned "standby addresses", describes devices in the 
SM^PERATIONAL state but have no device addresses assigned. The standby addresses are managed by 
the Fiddbus interface. Tbc third set of addresses are addresses outside the fim and second sds and refer to 
unnsed addresses. 

The smaU number of temporaiy addresses complicates autosensiiig and online address assignment 
Standby addresses are defined and utilized to support fimctionality of tt^ 

assigmnent operations. ITie assigned address set and the standby address set are ddined to be equal to the 
nmnberofpotentialdeWcescomiectedtothepnKesscontrdsystemnetwoiklin^ For example, if sixteen 
devices may be potentially corateded to the process control system network, then s^ 
are defined and sixteen standby addresses arc defined. 

TTie device revision infoimationindudesamamifittturcr-sidentification 
type (DEV-TYPE), a device revision (PEV41EV), and a device description revision (DD-REV). 
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In the ofOine state 2902 a field device is recently attached to a process control system network or is 
in the process of being commis sio ned or deoommissioned. The offline state 2902 includes device states 
having a phirality of parameter combinations. In a first offline state 2902, the system management sute is 
UNINTTIALIZED and the physical device tag is cleared. In a second offline state 2902. the system 
management stole is INmALIZED and the physical device tag is read fiom the physical device and 
displayable on a screen. In either of the offline states 2902, the device address is a temporaiy address, the 
revision information is not available, and the device identification is read from the device and displayable on 
the screen. 

In the unrecognized state 2904, the fidd device physical device tag and the device identification do 
not match the values that arc commissitmed for a device that is connected to the process control system 
network. The unxccognized state 2904 indudes device states having a plurality of paiameter combinations. 
In a first unrecognized state 2904. the system management state is INITIALIZED with a device address that 
is a temporary address. In a second unrecognized state 2904, the system management state is SM- 
OPERATIONAL with a device address that is a standby address or an assigned address. In cither 
unrecognized state 2904, the physical device tag is read from the device and displayable on the screen, the 
device revision is not available, and the device identification is read from the device and displayable on the 
screen. 

In the standby state 2906, the field device is not yet autosensed and is therefore not available for 
configuration in the control strategy or included in Link-Active-Schedulcr (LAS) schedules of the system 
management configuration. In the standby state 2906, function block execution and link communications are 
disabled. Note tiiat a Link-Activc-Scheduler is a deterministic centralized bus scheduler that includes a list 
of transmit times for all data bufifecs in all devices that arc to be cyclically transmitted. When a device is due 
to send a data buffer, the Link-Active-Scheduler issues a compd data (CD) message to the device. Upon 
iccdpt of tiie CD message, the device broadcasts or "publishes" the dau in the buffer to all devices on a field 
device bus and the broadcasting device is defined to be a "publisher". Any device that is configured to recdve 
the dato is defined to be a "subscriber". Scheduled data transfers are typically used for the regular, cyclic 
transfer of control loop data between devices on the fieldbus. 

In the standby state 2906, the system management state is SM-OPERATIONAL, tiie physical device 
tag is equal to the device identification, and the device address is a standby address. The device revision 
information is read from the field device and displayable. The device identification is read from the device 
and displayable on the screeiL 

The unbound state 29 10 is a configuration placeholder for a fidd device that is to be physically 
attached subsequenfly. The unbound state 2910 siq)ports configuration of control strategies utilizing the 
fimction blodcs in a field device that is not yet connected. In the unbound state 2910, the system 
management state is not yet applicable but the physical device tag is specified by a usar and the device 
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address is assigned by the user. The device revision infonnation set according to the most recent commission 
or configuration. The device identification is cleared. 

In the commissioned state 2908, the field device is available for control strategy configuration and 
installation. The system management state is SM-OPERATIONAL, the physical device tag is specified by a 
user, and the device address is assigned by Che user. The device revision information is read from the field 
device and diq>layable on the soeen. The device identification is read fi:om the field device, stored in a field 
configuration da t abase, and displayable on a di^lay screen. 

Scvoal operations or '"use cases" arc defined for conirolling commissioning and decommissioning 
of field devices. 

Referring to FIGURE 30, a flow chart iUustrates a first operation or ^isc case" which describes an 
operation of commissioning a new device 3000. Prior to the conmiissioning of the new device, the Fieldbus 
intcrfecc is opcrationaL A device is connected to the process control system network. The device either has 
no physical device tag or has a physical device tag that is equal to the device identification. 

The operation of commissioning a new device 3000 results in a condition in which the device is 
assigned a new physical device tag and a device address, and the device is ready for function blodc 
configuration. The new field device is entered into the process control system network database v^th the 
device identification bound and the device revision information set. An engineering software tool that 
displays the process control system network status displays the new device as a COMMISSIONED device. 

In a first step 3002, the field device appears in the "live list" at a temporary address. A "live list" is 
a list of all devices tiiat are properly responding to a pass token (PT) message. All devices on a fieldbus are 
allowed to send unscheduled messages between the transmission of scheduled messages. The Link- Active- 
Scheduler grants permission to a device to use the fieldbus by issuing a pass token (PT) message to the 
device. What the device receives the PT, it is allov^ to send messages until the messages arc complete or 
until a maximum allotted token hold time has c^ired. As a highest priority activity, the Link-Activc- 
Scheduler accesses a CD schedule containing a list of actions that are set to occur on a cyclic basis. At a 
scheduled time, the Link-Active-Scheduler sends a compel data (CD) message to a specific data bufier in the 
fidcfinis device. The device immediately broadcasts a message to all devices on the fieldbus. The Link- 
Acth«-Scheduler performs remaining openitions between scheduled transfCT^^ The Link-Active-Schedoler 
continual^ adds new devices to the field bus by periodically sending probe node (PN) messages to addresses 
that are not on the live list If a device is present at the address and receives the PN. the device immediately 
returns a probe response (PR) message. If a device responds with the PR message, the Link-Active-Schcdnler 
adds the device to the live list and confirms Iqr sending the device a node activation Adcvicc 
ronains on the live list so long as the device responds properly to PTs. When a device is added or removed 
from the live list, the Link-Active-Schednler broadcasts changes to the live list to all devices to allow each 
device to maintain a cunm copy of the live list 
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In a second step 3004, the interface queries the field device using a system management identify 
service (SM-IDENTIFY) and d^etmines whether the field device is in the UNINITIALIZED state with no 
pitysical device tag set or in the INITIALIZED state having a physical device tag that is equal to the device 
identification. The interface then allocates 3006 a standby address for the field device. 

A logical step 3008 directs that a previously UNINriTALIZED device, in stq> 3010. sets the physical 
device tag of the field device identical to the device identification using a set physical device tag service 
(SET4>D-TAG), therdsy placing the field device in the INTTIALEED state. The standby address is sent to 
the field device 3012 using a set address service (SET-ADDRESS), advancing the field device fiom the 
INITIALIZED state to the SM-OPERATIONAL state. At this point the field device appears in the "live list" 
at a standby address 3014. Device revision information is read from the resource block 3016. In step 3018, 
an executing software engineering tool displays the field device as a STANDBY device. 

In stq) 3020, a new user assigns a new physical device tag to the field device. The pl^sical device 
tag is constrained to be unique and not the same as the device identification. During the assignment of the 
physical device tag, a device address is assigned to the field device using a software engineering tool and the 
Unk-Activc^chcduler takeover preference is set to "selectable". The device revision information is read 
torn the field device and written to the process control system networic dat^e. The inierfece changes the 
state of the field device 3022 to the INITIALIZED state using a clear address service (CLEAR-ADDRESS). 
The field device appears in the "live lisf * at a temporary address 3024, 

In a step 3026, the interface queries the field device using a system management identify service 
(SM-IDENTIFY) and recognizes the field device by the device identification. The interlace uses tiw set 
physical device tag service (SET-PD-TAG) to clear ti\e physical device tag 3028. Uiereby changing Oie field 
device state to the UNlNTnALIZED state. The set physical device tag service (SET-PD-TAG) is then used 
to send the assigned physical device tag to the field device 3030, changing tiie field device state to the 
INmALIZED state. The set address service (SET-ADDRESS) is caUed to send the assigned address to the 
field device 3032, placing the field device in the system management operational state (SM- 
OPERATIONAL). The field device appears in the "live list" at the assigned address 3034. In the process 
amtrol system network database, the device identification is bound 3036 to tiie device. The software 
engineering tool displays tiie field device as a CX3MMISSIONED device. 

Referring to FIGURE 31, a flow chart ilhistrates a second operation or *^ise case" which describes 
an operation of commissioning an unbound device 3100. Prior to the commissioning of the unbound device, 
tiie Fieldbus intafece is operational A field device has been created in tiie process control system network 
database and a physical device tag and a device address are assigned to tiie field device. However, tiie field 
device is not bound to a device identification. The process control system network database has also been 
initialized to contain device revision information read fhmittie field devi^^ A software engineering tool 
diqilays tiie field device as an UNBOUND device. The UNBOUND todcc to be commissioned is dtiier a 
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fidd device with no physical device tag or a field device having a physical device tag that is identical to the 

device identification. The UNBOUND fieM device is conunissioned to place the field device on the process 
control ^stem network link. 

The operation of conunisdoning an UNBOUND device 3100 results in a condition in which the 
device is amfigured with a physical device tag and an asdgned device address^ 
fiinctionblockconfigunaion. The new field device is entered into the process control system network 
database with the device identificationbound. An engineering software tool that displays the process control 
system network status disp^s the device as a COMMISSIONS) device. 

In a first step 3 lOZ. the field device appears in the "live list" at a temporaiy address. In a second stq> 
31H the itaabct qaedes the field device using a system management identify service (SM-IDENTIFY) and 
determines whether the field device is in the UNINTTIALIZED state with no physical device tag set or in the 
I^aTLUJZEDstatehavingapl^rsicaldevicetagthatisequaltod^ n« interfecc then 

allocates 3106 a standby address for the field device. 

A logical step 3108 directs that a previously UNINmALI2ED device, in step 3110. sets the physical 
device tag of the field device idemical to the device identification using a set physical device tag service 
(SET-TO-TAG), thereby placing the field device in the INITIALIZED state. The standby address is sent to 
the field device 3112 using a set address service (SET-ADDRESS), advancing the field device from the 
INITIALIZED state to the SM-OPERATONAL state. At this point the field device appears in the "live list" 
at a standby address 3114. Device revision information is read from the resource block 31K. In step 3118. 
an executing software engineering tool di^lays the fidd device as a STANDBY device. 

In step 3120, a usa assigns a physical device tag to the field device by associating the field device 
with the pnM»nfigured device. The device revision information is read from the field device to ascertain that 
the information matches the device revision information in the process control system network database for 
the pn«onfigured device. If the device revision information of the device does not matdi the database, the 
user may ovcnide the database, reading the device revision information from tiie fidd device and writing tiie 
infetmation to the process control system network database. Alternatively, the device revision information 
for an UNBOUND device may be made blank, aUowing any physical device to be bound witii the UNBOUND 
device. The inteifece changes the slate of the field device 3122 to the INITIALIZED state using a clear 
address service (CLEAR-ADDRESS). The fidd device appears in the "live Hsf' at a temporary address 3124. 

In a step 3126, the interface gneiies the fidd device using a >ya«n manag^^f ifHitify lervicc 
(SM-IDENTIFY) and recognizes the fidd device by the device identificatioa The interfiice uses the set 
physical device tag service (SBT-PD-TAG) to dear the pl^sical device tag 3128. the«by dianging the fidd 
device state to tite UNDOTIALIZED state. The set physical device tag service (SET-PD-TAG) is then used to 
send the assigned physical device tag to tite fidd device 3130. changing the fidd device state to the 
INTIIALIZED state. The set address service (SET-ADDRESS) is called to send the assigned address to the 
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field device 3132, pladng the field device in the sysiem management operatianal state (SM- 
OPERATIONAL). The field device appears in the "Uve list" at the assigned address 3134. In the process 
control system network database, the device identification is bound 3136 to the device. The software 
engineering tool displays the field device as a COMMISSIONED device. 

Referring to FIGURE 32, a flow chart iUnstiates a third operation or **use case" which describes an 
q>eration of decommissioning a device 3200. A field device is decommissioned for scvmi reasons. For 
example, when a Fieldbus device is obsolete, a user suqt wish to dear a netwoik intctconnection structure of 
nonfimctioning branches so that the process control system no longer expends resources on the obsolete 
device. Also, a us« suspect that a Fieldbus device is malfimctioning and degrading operations of a 
segment ofanrtwoik interconnection structure. The user may diagnose the problem by having the process 
control system ignore the suspected Fieldbus device temporarily to determine whether the remaining devices 
in the segment operate properly. 

Prior to the operation of decommissioning a device, the Fieldbus interface and the field device arc 
operational and tiic field device qipears in the five list at tiie assigned or standby address. A software 
engineering tool displays tiic field device as a COMMISSIONED or STANDBY device. The software 
engineering tool executes a routine thai prepares the field device for decommissioning, for example by 
clearing fiinction block tags and clearing an OPERATIONAL-POWERUP flag. 

The operation of decommissioning a device results in a condition in which the physical device tag of 
Uie field device is dearcd and tiie field device is prepared to be removed from tiie process control system 
network link. The process control system nctworic database entiy for the field device designates tiie device 
identification as in an unbound condition. The software engineering tool displays tiic device identification as 
an UNBOUND device and displays the physical device as an OFFLINE device. 

The operation of decommissioning a device 3200 begins when a user selects a "Decommission" 
operation for tiie field device 3202. A gi^hic user interlace includes a software cn^ncering tool tiiat issues 
a "Decomnrission" command to an appropriate controller witiiin tiie process control system. The 
decommission command spedfies a target I/O subsystem, card and port identifiers, and tiie device 
identification of tiie field device to be decommissioned. The device identification is spedfied since anotiicr 
device witfi the same ph^^cal device tag m^ be present in an UNRECOGNIZED state. The interface 
changes tiie state of tiic field device 3204 to tiie INITIALIZED state using a clear address service (CLEAR- 
ADDRESS). The field device appears in the **live lisl** at a tenqioraiy address 3206, 

In a stq> 3208, the intei^ queries the field device using a system management identify service 
(SM-IDENTIFY) and lecognizes the field device by tiie physical device tag and tiie device idcntificatioa 
The interface uses tiie set physical device tag service (SET-PD-TAG) to clear tiie physical device tag 3210, 
thereby changing the field device state to the UNINITIALIZED state. 
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In the process control system networic database, the device identification is unbound and the 
software engineering tool displays the field device as an UNBOUND device 3212. In a next st^ 3214. the 
software oiginemng tool displays the field device as an OFFLINE device. 

A network interfecc card stores a designation that the field device has been decommissioned 3216 
and does not move the field device to a STANDBY address unless directed by the user. Ifthe 
decommissioned device is not move to a STANDBY address, the interfecc card tracks the field device untU 
the field device advances off the live list 

Rcfening to FIGURE 33, a fiow chart iUustiates a fourth operation or "use case" which describes 
an operation of attadung a commissioned de\ ice without enablement of operational powerup 3300. Prior to 
the operation of attaching a commissioned device 3300, the Fieldbus interface is opciationaL The 
configuration of the Fieldbus imerfeoe inchides the field device in an attached condition. The physical device 
tag and the device identification of the field device arc matched. Following the operation of attaching a 
commissioned device 3300, the field device has an assigned address. 

The field device appears in the "live list" at a temporary address 3302. In a step 3304, the interface 
queries the field device using a system managemait identify savice (SM-IDENTIFY) and recognizes the 
field device by the physical device lag and the device identification as part of the Fieldbus intcrfece 
configuration. The s« address service (SET-ADDRESS) is called to send tfie assigned address to the field 
device 3306, placing the field device in the system management operational state (SM-OPERATION AL). 
The field device appears in the •*live list" at the assigned address 3308. 

Referring to FIGURE 34, a flow chart illustrates a fifth operation or "use case" which describes an 
operation of replacing a device 3400. A device is replaced by decommissioning the current field device 3402 
connected to tiie process control system network link, if possible, and commissioning a rq)lacemcnt to the 
UNBOUND device 3404, The step of decommissioning the current field device 3402 is described in detail 
with reference to FIGURE 32. The stq> of commissioning a replacement to die UNBOUND device 3404 is 
described with reference to FIGURE 31. 

Referring to FIGURE 35, a fiow chart illustrates a sixth operation or "use case" which describes an 
operation of attaching an UNRECOGNIZED device 3500, Prior to the operation of attaching a 
commissioned device 3300, the Fieldbus interface is operational A field device is attached which has a 
physical device tag and a device identification tiiat is not configured for the current process control system 
nctwoik Hnk. FoUowing tiie operation of attaching an UNRECOGNIZED device 3500, the field device is 
identified and tiie software ooginemng tool displ^ die device as n UNRECOGNIZED device. The 
operation of attaching an UNRECOGNIZED device 3500 ma^ 
engineering tooL 
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The field device appears in the "live list" 3502. In a step 3504, the intei^ queiies the field device 
using a system management identify sendee (SM-IDENTIFY) and determines that the physical device tag 
and the device identification do not match a field device in the present configuration. 

Referring to HGURE 36, a flow chart iUostiates a seventh operation or "use case" which describes 
an operation of decomniisaoning an unrecognized device 3600. Prior to the operation of decommissioning 
an unrecognized device, the Fieldbusinteifece is operational The field device is identified which has a 
physical device tag and a device identification that are not configured for the present process control system 
nctworiciink. A software engineering tool displays the field device as an UNRECXXi 

The <^)eration of decommissionitig an unrecognized device 3600 results in a condition in which the 
phg^cal device Ug of the field device is cleared and the field device is prepared to be removed from the 

process control system netwoit link, llie software engineering tool di^lays the fidd device as an OFFLINE 
device. 

The operation of decommissioning an unrecognized device 3600 begins when a user selects a 
Decommission'' operation for tiie field device 3602. A graphic user interface includes a software 
engineering tool that issues a "Decommission- command to an appropriate controller within tiie process 
control system. The decommission command q>ecifies a target I/O subsystem, card and port identifiers, and 
the device identification of die field device to be decommissioned 

If the field device is in tiie INITIALIZED stale, lo^c step 3604 directs tiie decommissioning 
operation 3600 to a clear tiie physical device tag step 3612. Otiierwise, the interfece changes tiie state of tiie 
fidd device 3606 to tiie INITIALIZED state using a clear address service (CLEAR-ADDRESS), The field 
device appears in the **livc .list" at a temporaiy address 3608. 

In a step 3610, the inter^ queries the field device using a system management identify service 
(SM-IDENTIFY) and recognizes the field device by tiie physical device tag and the device identificatioa 
The interface uses tiie set physical device tag service (SET-PD-TAG) to clear the physical device tag 3612, 
tiiereby changing tiie field device state to tiie UNINITIALIZED state. In a next stqj 3614, tiic software 
engineering tool di^lays the field device as an OFFLINE device. 

A networic interfebe card stores a designation that tiie field device has been decommissioned 3616 
and does not move die field device to a STAM)BY address unless directed by the us^. Ifthe 
decommissioned device is not move to a STANDBY address, tiie interface card tracks tiie field device until 
the field device advances ofif the live list 

Referring to nCURE 37. a flow chart illustrates an eightii operation or "use case" which describes 
an operation of pladng a decommissioned device in a standby condition 3700. Prior to the operation of 
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placing a decommissioned device in a standby condition 3700» the Fieldbns intez&ce is operationa]. A field 
device is decommissioned and in the OFFLINE state. 

The operation of placing a decommissioned device in standby 3700 results in a condition in which 
the field device is placed at a standby address with the physical device tag of the field device set identical to 
the device identificatioa The software engineering tool displays the field device as a STANDBY device. 

The operation of placing a decommissioned device in standby 3700 begins when a user selects a 
"'Place in Standby^ operation for the field device 3702. A graphic user inleiiace includes a software 
engineering tool that issues a "Place in Standby^ command to an appropriate omlroll^ within the process 
control system 3704. The decommisaon command specifies a target I/O subsystein, card and port identifie^^ 
and the device identification of the field device to be placed in standby. 

The interface allocates a standby address 3706 for the field device. The set physical device tag 
service (SET^D-TAG) is then used to set the physical device tag identical to the device identification 3708, 
changing the field device state to the INITIALIZED state. The set address service (SET-ADDRESS) is called 
to send the standby address to the field device 3710, placing the field device in the system management 
operational state (SM-OPERATIONAL). The field device ai^pears in the ^live lisf* at the ^andby addiiess 
3712. Device revision information is read fiom the resource blodc 3714. In stq> 3716, an executing software 
engineering tool displays the field device as a STANDBY device. 

A user may subsequently conunission the field device 3718, either by creating a new device or 
binding the field device to an UNBOUND device in the process control system network database. The 
techniques for commissioning a device are described with respect to FIGUR£s 30 and 31. 

Refening to FIGURE 38, a schematic block diagram illustrates a program stmcture of a process 
control configuration program for defirdng a process configuration using a plurality of control languages. 
The module editor 3820 is a software piogiam that executes on the CPU 116 within a workstation snch as the 
engineering workstation 106. Using the module editor 3820, a user activates one language editor of multiple 
control language editors including an attribute editor program 3830, a Function Block EditA^ew/Debug 
program 3840, a Sequential Function Chart program 3850, a Ladder Logic program 3870 and a Structured 
Text program 3890. The multiple control language editors operate with compatible databases and interfaces 
so that a common control strategy is defined using the different control language editors. The look and feel 
of the difiermt control language editors is similar so that a user easily and efficient^ may use difierent 
editors for diff^ oit purposes to best take advantage of diffoient aspects of the languages. 

The module editor 3820 is the fimdamental routine for configuration amy and is used to cieate» 
edit, and re-use control and equipinent module instances and library modules defined by the SPSS standard. 
The module editor 3820 siqiplies a graphical technique for configuriiig, visoalizing, and navigating imiltiple 
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modules that combine to form a oontiol strategy. The module editor 3820 is also used for module linking and 
defining module containment 

The module editor 3820 supplies access to all aspects of configuration of a module including suppon 
for algorithm defudiion, as well as infonnation gathering relating to alarms, events, histoiy, condition, help, 
components and attributes. 

The module editor 3820 includes various features that faciliute navigation through a contnrf system. 
For cxan^lc, the module editor 3820 filters attributes on user-defined key words to supply a focused attribute 
configuration view. FurthOTUore, the module editor 3820 inchides a fast install capability which defaults to 
performing the install to aU devices afifected by changes to the module. The control strategy is transferred 
from the editors into nmtime engines using an install script A plurality of control language execution 
engines execute the control strategy on one or more controller/ multiplexers 110. 

Off-Unc configuration siq)ports *work in progress* for an existing module s control strategy. When 
the new strategy is complete, it can be installed to the existing module. This 'work in progress* can be 
flagged to not allow it to be installed. 

The attribute editor program 3830 is a control program operated by a user to view and edit 
parameter values associated with a control module or control algorithm elements including function blocks, 
ladders, composites, and the like. The attribute editor program 3830 is used on-line to configure a control 
module. On-line, the attribute editor program 3830 is used to view and edit data. Attributes are defined to 
fiimish module-level access to parameters contained within a module. The attribute editor program 3830 is 
activated by the module editor 3820 and other control language editors. The attribute editor program 3830 
presents a simple attribute configuration view using a graphical navigation tree pathway display to 
consolidate the parameters to be configured for a module. A user activates the attribute editor program 3830 
and navigates through the graphical navigation tree to find a particular attribute. When an attribute is 
selected, the attribute is displayed cither using an application window or as a dialog depending on the context 
fipom which the display is evoked. The attribme editor program 3830 feciUtates configuration by supporting 
copy, paste and bulk change of attributes using a drag and drop technique. The attribute editor program 3830 
is used to define attribute parameter values but not to install attributes since attributes are instal led when the 
module containing the attribute is installed. As attribute parameter values arc entered by a user, the attribute 
editor program 3830 performs error checking. The attribute editor program 3830 allows a user to sort and 
view data with typical spreadsheet capabilities, including esqiansion and reduction of the number of columns, 
or by contaimnent 

The Function Block EditA^ew/Debug program 3840 is a control program opiated by a user to 
define a control strategy by assembling function block dements designated under the Fieldbus Foundation 
and DSC 1131-3 standards. The function block program 3840 is inq)lemented in a function block execution 
engine which operates in a controllei/ multiplexer 110. The fimction block execution engine executes 
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fimction block control algorithms using a Function Block Lftnuy 3S42. The lunctioB block pnigiam 3840 
suppUes a graphical editor for creating, editing and reusing control strategies using function blocks stored 
within a Function Block Library 3802 and other defined control modules, for example connol modules 
defined for usage by other application programs. A created control strategy is saved as a reusable library 
component in the Function Block Library 3802 for subsequent usage or for usage by another appHcation 
program. ITie function block program 3840 also creates, edits and reuses control structures for HART and 
FFtiming field devices. Hie fimction block and module constinients of a control strategy are not confined to 
aparticolar device, but are lather partitioned across mnltiple control devices, including HART and FF timing 
fidd devices. 

A fimction block or module indudes attribmes that are modified using the fimction block program 
3840. Any attribute in the system, unless security protected, is accessed through the navigation tree pathway 
for tfiat attribute and is read or written firom the function block editor. 

The fimction block editor program 3840 supports an oflMine creation and debug fimction for control 
strategies of modules and reusable horary components. During off-line operation, a control device is not 
connected to the network. Offline operation is usefiil for initializing attributes and patamettrs brforo the 
control device is connected using an attribute editor 3842 of the fimction block editor progiam 3840 since, 
during oflr-Iine operation, multiple control strategies can be open, and configurations can be copied and 
pasted between strategies. 

The fimction block editor program 3840 also supports on-line graphical editing, viewing and 
ddnigging of fimctions blocks during operation, induding display of block input and output values. Selective 
on-line edit and debug mode options indude single step, forced inputs and breakpoint options, fiw example^ 
One window is used for on-line editing and debugging so that the user may correct an inconsistent parameter 
value in place. Input vataes during on-line editing are chedced for consistency with offline editing values, 
and disallowed if inconsistent 

Hardcopy ou^ infiinnation generated by the fimction block editor program 3840 indudes 
gi^cal ic^nesentation and configuration information such as blodc attribute and parameter values. 

Several feabues of the fimction block program 3840 fadUtate user sappoA induding tiic creation of 
reusable Sbraiy components, user conversation support, and input error dwddng. User conversation siqjpoit 
withinstepactionsallowsauserloconfigurepqp-updialogswithrBsponses. Reusable library components 
are developed to simplify engineering during configuration and execution so that a sin^e Function Blodc 
Diagram (FBD) acts as a subroutine fiw multiide modules or FBDs during execution. 

The Sequential Function Chart (SFQ EdilATiew/Debug program 3850 is a control program operated 
by a user to define a control strategy by assembling stqis. step actions and transitions designated under JEC 
1 131-3 standards. The sequential fimction diart program 38S0 is implemented in an SFC execution engine 
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v/tuch operates in a coaUoUer/ multiplexer 1 10. The SFC execution engine executes sequential function 
chart control algorithms inchiding steps, actions and transitions. The sequential fiinction chart program 
3850 supplies a graphical editor for creating, editing and reusing sequential control suategies using 
sequential fiinction charts. The sequential function chart program 3850 supports execution of paiallel logic 
paths. Executing sequential function charts arc associated with a module, at least for the duration of SFC 
execution. 

A sequential function Chan indudes attributes that are inodified u^ 
piogiam3850. Any attribute in the qrstem, unless securi^ protected, is accessed fran a 
function chart execution. 

The sequential function chart program 3850 supports an off-line creation and debug function for 
control strategies of modules. During off-line operation, a control device is not connected to the network. 
Offline operation is useful for initializing attributes and parameters before the control device is connected 
using an attribute editor 3842 of the sequential function chart program 3850 since, during off-line operation, 
multiple control strategies can be open, and configurations can be copied and pasted between strategies. 

The sequential function chart editor program 3850 also suj^orts on-line graphical editing, viewing 
and dd>ugging of sequential function charts during operation, including a "live" display of attribute values. 
Selective on-line edit and debug mode cations include single step, forced inputs and brcalqjoint options, for 
example. On-line editing includes s^ng of a breakpoint for executing a control strategy while changes are 
made in the strategy. One window is used for on-line editing and debugging so that the user may correct an 
inconsistent parameter vahie in place. htpxA values during on-line editing are chedced for consistency with 
off-line editing values, and disallowed if inconsistent. The sequential function diart program 3850 supports 
runtime view including a display of steps, actions, currently-executing transactions and attribute values. 

Hardcopy output information generated by the sequential function chart program 3850 includes 
graphical representation and configuration information such as step actions. 

Several features of the sequential function chart program 3850 fecilitate user siq)port including the 
creation of reusable library components, user conversation siqjport, and input error checking. User 
conversation support within stq> actions allows a user to configure pop-up dialogs with responses. Reusable 
library components are developed to simplify engineering during configuration and execution so that a single 
Sequential Function Chart (SFC) acts as a subroutine for multiple modules or SFCs during cxccutioa 

The Ladder Logic program 3870 is a control program operated by a usar to define a control strategy 
using ladder elements and function blocks in combination in a ladder logic diagram. The ladder logic 
program 3870 is implemented in a Ladder Logic engine which operates in a controller/ multq>le3w 110. Tlie 
ladder logic engine executes ladder control algorithms including coils, contacts, arul several standard 
function blocks. The Ladder Logic program 3870 includes a basic discrete control ladder logic library 3872 



W098X3fi335 



-66- 



PCrAJS98/01573 



which indudes the coinponents far solving basic discrete control operations. These operations aie logical 
extensiQiis of lEC 113 1-3 standards including elements such as coils, contacts, timeis. flip/flops, edge 
triggeis and counters with one output connection defined per ladder rung. The Ladder Logic program 3870 
also supports placement of user-defined blocks within a ladder logic diagram. A ladder logic diagram is 
applicable lo a function block that supports power flow in which the state of execution is determined by 
whether "powe," is flowing through a "rung" in the ladder. Power flow is somewhat analogous to data flow 
in a logic diagiam. The applicable fimction Modes, alone, are displayed by the Ladder Logic program 3870 
on a ladder logic palette. 

The Ladder Logic program 3870 may be exclusively used by a user to configure and debug a control 
strategy or a ladder diagram sheet may be used as a composite within another ladder logic sheet, a function 
block diagram sheet or an sequential fimctioa chart sheet A ladder logic sheet can hold composite ladder 
logic diagrams, function blodc diagrams or sequential function dart sheets. A ladder logic element can read 
and write to attributes in other sheets and in other modules. 

Ladder logic diagrams support both on-line and off-line editing. User can switch fiom debug 
functionality to the edit mode on a spedfic ladder logic diagram to make structural changes in the control 
strategy. The usw change any parameter ftom either the debug view or the edit vkw. 

The Ladder Logic program 3870 indudes a debug fimctionaUty that indudes a display of power 
flow, parameter values and energized or de^gized states. The ladder togic debug functionality is the 
substantially the same as the debug fimctionality of the Sequential Function Chart editor program 3850 in 
which the user forces inpm values, sets breakpoints and the like. The Ladder Logic program 3870 supports 
ladder logic simulation, historical data collection and mode, alarm and status report generation. 

Refaring to HGURE 39A, a screen presentation of a configuration screen 3900 is dq>icted whid» 
is generated by a configuration program using the fimction block editor 3840. The configuration screen 3900 
indudes a navigation portion 3902 and a screeiHfpedfic portion 3904. The navigation poition 3902 inchides 
navigation tobs 3910 which aUow a user to access particular sedions of the configuration program. In the 
iUustratrve state of the configuration screen 3900. the configuration program is awaiting a user entry of a 
configuration command. Navigation tabs 3910 indicate several primitive fimctions for the entty into a 
fimction block including a navigation tab 3912 for selecting a simple set dominant (SR) flip-flop, a 
navigation tab 3914 for selecting a simple subtract block, a navigation tab 3916 for sderting a simple timed 
pulse Mode a navigation tab 3918 for selecting a simple transfer block, and a navigation tab 3920 for 
sdediiig a simple cxdusive<)R (XOR) block. The navigation tabs 3<»10 also include a blodc assistant 3922 
tab for inserting a fimction blodc . The screen-spedfic portion 3904 iUustrates a fimction blodc 3924 Uiat is 
to be configured, induding configuration of attributes and connections with other fimction Modes. 

The block assistant 3922 tab is selected to insert a fimction Mode. 
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Refening to HGURE 39B. a Selection screen 3930 is displayed in response to the selection of an 
insert function block. The selection screen 3930 also includes a selection portion 3932 and a soeea-specific 
portion 3934. The screen-specific portion 3934 includes an entry block 3936 for entering the name of a new 
block that is to be created. The selection portion 3932 includes a plurality of selection tabs 3938 indoding a 
fiinction block 3940 tab, an embedded block 3942 ub, a Unked composite 3944 tab and a nuxlule block 3946 
tab. The selection portion 3932 also includes a variety of buttons wliich fimiish navigation functions, 
including a Back button 3948. a Next button 3950 and a Cancel button 3952. The Back button 3948 takes 
the user to the previous screen presentation in strict historical order. The Next button 3950 takes the user to 

the screen presentation ^^mqwiale for the sdections that are made on the currem screen The 
cancel button 3952 temiinates the selection. 

The embedded blodk 3942 tab is selected to insert an embedded block. 

Referring to WIGVKE 39C, a Choice screen 3960 is evoked to allow the user to select a control 
language editor for configuring the embedded block, either a fimctkm block editor using selection 3962 or a 
sequmtial function chart editor using selection 3964. 

The selection 3964 is chosen to utilize the sequential fiuiction chart editor. 

Referring to FIGURE 39D. a screen presentation of a configuration screen 3970 is illustrated in 
whidi the iunctwn block 3924 is configured using the function editor 3840 and a ne»^ created Mock 3972 is 
configured using the sequential function chart editor 3850. 

Editing of newly created block 3972 is selected so that the sequential function chart editor 3850 is 

invoked. 

Rcfcning to nCURE 39E, details of a Uk newly created bhxJc 3972 are shown in the screen- 
spedRc portion 3934 of the configuration screen 3980 including attributes 3982 and a stqi 3984. The 
navigation portion 3986 of the configuration screen 3970 no longer Usts navigation tabs nslating to function 
blocks, but raUier includes navigation labs 3988 relating to a step 3990, a transition 3992. a termination 
3994. and input terminal 3996 and an output terminal 3998 to define die steps and transitions of a sequential 
fiincdoiL 

Refetriag to nCURE 40, an object model shows object relationships of various objects for handling 
alarm and event functions. Various conditions are defined to be "events" including Alarms, Alam 
acknowledgments, user changes (writing attributes, invoking methods, log-in/out), configuration changes to 
the "run-time" system (installations, dc-installs. etc.). Sequential Function Chart (SFC) state changes. 
Operator Attention Requests (OARs), and other miscellaneous Events (non-alarm state ttansitions including 
equipment state changes). 
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A common chaiactensdc for all types of events is that the occurrence or state transition of an event 
can be recorded in a Event Jonmai. All events are assodated with one (or moie) plant areas. Event 
occurrence records (RtEventOccurrenceRecord 4040) arc captured in the Event Journal, or Journals, 
(RtEventJoumal 4020) designated for the associated plant area (RtPlantArea 4010). 

A user activates the Event Joutnal» typically using a woikstation, fay configuring one or more Plant 
Areas within which the activated EvoU Journal captoies events. On-line operation of the Event Journal is 
modified under user control by disabling or enabling spedfied classes of events to be recoided . 

The user configures an Alarm behavior by creating Alarm Atributes (RtAttribute 4032) in Control 
Modules or Equipment Modules (RtModule 4030). An Alarm Attribute furnishes reference to ai^ boolean 
Attribute within the Control Module or Equipment Module containing the Attribute. Alarm Attrifafutes are 
created only at the Module levd. Alarm Attributes are not created in Composite Function Blocks. 

Referring to FIGURE 41, a state transition diagram illustrates alarm attribute states. A user either 
disables or enables an Alarm Attribute. When disabled 4110, the Alarm Attribute appears in a "normal" 
condition, called an "Inactive and Acknowledged" condition. The Disabled/Enabled condition of an Alarm 
Attribute is changed either on-line, by an Operator, or automatically by a control algorithm in the system. 
The initial Disabled/^iabled condition is set at configuration time. An enabled Alarm Attribute has either an 
Active condition 4116 or 4118 or an Inactive condition 4112 or 41 14. The Alarm is Active ( ^'in alarm**) 
when the referenced boolean Attribute is TRUE. The Alarm Attribute is optionally configured to invert the 
sense of the alarm state, so an Alarm Attribute with .INV characteristic TRUE operates is if the referenced 
Attribute's value of FALSE indicates an ''in alarm" condition. The Active/Inactive condition is driven by 
the state of the referenced Attribute so that the Active/Inactive condition is not directly changed by the 
Operator or another control algorithm. 

While Enabled, an Alarm Attribute has either an Acknowledged 4112 or 4116 or Unacknowledged 
state 4114 or 4118. The Alarm Attribute is placed in the Unacknowledged condition only if the Alarm 
Attribute makes a transition firom Inactive to Active state, unless automatically acknowledged. An Operator 
or another control algorithm may acknowledge the Alarm, changing the Alarm Attribute to the 
Admowledged conditioa 

An Alarm Attribute is either automatically acknowledged (AACK'd) or not automatically 
acknowledged. AACK is dcleimiiied from the current Alarm priority. A user-configured, system-wide table 
detennines AACK behavior. For example, the table may designate that all "LOW" priority Alarms are 
automatcally acknowledged (AACK is TRUE), all "MEDIUM" and "HIGH" priority Alarms are not 
automatically acknowdedged (AACK is FALSE). When AACK is TRUE, the alarm is never placed in an 
Unacknowledged condition. 
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The combined operation of the Enable/Disabled. Active/Inactive, and 
Acknowledged/Unacknowledged conditions results in user^T>le states for an Alann Attribute that aie 
shown in FIGURE 41. 



10 



An enabled Alann Attribute initialfy goes to the Inactive/Ack'd Stale 41 12, and may immediately 
5 transition to either AciivcaJnadc'd 4tl4 or Activc/Adc'd 4116. The transition to Activc/Ack'd 4116 is 
accompanied by a standard "transition" bdiavior for Alarms in v^ch the transiUon is timcstampcd and the 
event is recorded in the event journal, for eicanqile. 

The Alam Attribute has muWple fields that provide a user-visible interface, A CUALM "current 
alarm- field is "OK" when the Alarm Attribute is in the Disabled state 41 10, the Inactive/Ack'd state 4112 or 
Inactive/Unack'd state 4114, Otherwise CUALM is the wordAralue associated with the configured Alarm 
Type. A DESC "description** field has an alarm description that is generated when the Alam Attribute 
dianges state. The DESC fidd is inidalizBd to the empty string. A LAALM "latched alarm" field is "OK" 
when the Alarm Attribute is in the Disabled state 4 1 10 or the Inactive/Ack'd state 41 12. Otherwise the 
LAALM field is the word/value associated with the configured Alarm Type. The LAALM field presents 
"latched" alarm activations, enabling Acknowledgment even if the duration of being Active is voy short A 
NALM "unacknowledged alarai" field indicates the Adoiowledged/Unacknowledged condition of the Alarm 
Attribute. The NALM field is used to determine when alarm summary entries can be removed. AnENAB 
"alarm enabled" field indicates the current Enabled condition for the Alarm Attribute. An lENAB "alarm 
initially enabled" field indicates the configured Enabled condition for the Alarm Attribute, An INV 
"invened input" field indicates whether the value of an associated boolean Attribute is inverted before alarm 
processing. The INV configurable characteristic permits an Alarm Attribute reference nonnally TRUE 
boolean Attributes, for exan^le an Attribute holding a discrete input A PRI "alarm priority* field indicates 
cuncnt priority (High/Mediura/Low) of an Alarm Attribute. TABLE II shows the boolean Attributes as 
foUows: 



15 



20 













cv 

(or none) 


(same as LAALM) 


(same as LAALM) 


(same as 
LAALM) 


(same as 
LAALM) 


CUALM 


Read: [view] 
Write: N/A 
Config: N/A 


"OK" 

(alarm word) 


0 

(alarm type 
number') 


0 

(alarm type 
number) 


DESC 


Read: [view] 
Write: N/A 
Config: WA 


(description 
generated at the 
time of alarm state 
change) 


N/A 


N/A 


ENAB 


Read: [view) 
Write: [alarms] 
Config: N/A (initio 
lENAB) 


"NO" 
••YES" 


0,0 
1.0 


0 
1 


INV 


Read: [view] 
Write: N/A 


"NO" 
**YES" 


0.0 
1.0 


0 

I 
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Config: (configl 








lENAB 


Read: [view] 


"DISABLE" 


0,0 


0 




Write: N/A 


"ENABLE*' 


1.0 


1 




Conflg: [config] 










Instance oveirideable 








LAALM 


Read: (view) 


"OK" 


(alann 


(alann type 




Write: N/A 


(alann word) 


number) 


number) 




Config: N/A 








NALM 


Read: [view] 


"NO" 


0.0 


0 




Write: [operate] 


"YES" 


1.0 


1 




Config: N/AOnitFALSE) 








PRI 


Read: [view] 


"LOG" 


3.0 


3 




Write: [alanns] 


"LOW" 


2.0 


2 




Config: [config] 


"MEDIUNT 


LO 


1 




Instance ovenide^le 


"HIGH" 


0.0 


0 



The pnKess control system 100 consolidates many potential Active Alarm conditions into a short list 
of "highest priority" alanns. A selection criteria is used to select the highest priority alanns for 
consolidation. The selection criteria includes analysis, ia order of decreasing preference, the Acknowledged 
condition with the Unacknowledged condition having precedence over the Acknowledged condition, the 
5 Alarm Priori^ in order of High then Medium then Low precedence, and the Time of Detection with the 
newest timestamp gaining precedence. 

Alarm Consolidation is available at the SP88 Module level and the Plant Area leveL Alarm 
consolidation is accessed via a pre-defined Attribute name "ALARMS" available on SP88 Modules (Control 
& Equipment) and Plant Areas. ALARMS is an indexed Attribute, where the index selects the Nth highest 
10 priority alarm in the consolidation (e.g. ALARMS[1] accesses the highest priority Alarm, ALARMS(21 
accesses the second highest priority Alarm, etc.) Thus, for example, *AREAI/FIC101/ALARMSI11* 
references the highest priority Alarm in Module FIClOl and *AREA1/ALARMS[2]* references the second 
highest priority Alann in Plant Area AREAI. The maximum index supported on the ALARMS Attribute is 
5, 

15 The Fields supported on the ALARMSIN] Attribute include the LAALM "latched alarm" field 

which indicates the Active Or Unacknowledged conditions of the Nth priority Alarm Attribute. The LAALM 
Field is in the alann word, or alarm type value, of the Nth priority Alarm Attribute during the 
ACTIVE/UNACK'D, ACmVE/ACK'D, or INACTIVE/UNACK'D states. The NALM "unadoiowledged 
alarm" field indicates the Acknowledged/Unacknowledged condition of the Nth priority Alarm Attribute. 

20 The PRI "alarm priority" field indicates the configured priority (High/Medium/Low) of the Nth priority 
Alann Attribute. A TAG ''alami Tag" fidd returns a fiilty qualified Attribute refeim:» string (exd 
Field) for the Nth priority Alann Attribute. A MODULE "alarm Module" field indicates the SPSS Module 
(tag) vMch has the Nth priori^ Alann. The MODULE tag letnms a Module reference string which can be 
used to access the '^rimaiy control display" attribute for that Module. 
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Some Fidds arc supported on the ALARMS Attribute oidy at ^ Ifanindex 
value is applied for tliese fields, the index value is ignored. The SPSS Module levd ALARMS Attribute 
fields include an ENAB "alarm enabled** field which indicates the current Alarm Enabled condition for the 
Module. A PRIAD "priority adjustmenr field is a number (normally 0) which is added to the current 
Priority of each Alarm Attribute in the Module when determining the cflfectivc Priority of an Alarm. The 
PRL\D Module-wide adjustment is used to decrease the Alarm Priorities of all the alarms in a Module, 



permitting diminished Akurm visibility, TABLE in describes the ALARMS Attribute, in detail, as foUows: 



1 TABLE m. i 


ittrilmte; ALARMSIN] M 


- L.5, 1 is highest priority alarm) 


1 












CV 

(ornone) 


(same as LAALM) 


(same as 
LAALM) 


(same as 
LAALM) 


(same as 
LAALM) 


ENAB 


Read: (vicwj 

Write: [alarm] 

Config: N/A (init TRUE) 


"NO" 


0.0 


0 
1 


LAALM 


Read: [view] 
Write: N/A 
Config: N/A 


"OK" 

(alarm word of 
Nth alarm) 


0 

(alarm type 
number of Nth 
alarm) 


0 

(alarm type 
number of Nth 
alarm) 


MODULE 


Read: [view] 
Write: N/A 
Config: N/A 


Module name 
for Nth alarm 
attribute. 


N/A 


N/A 


NALM 


Read: [view] 
Write: N/A 
Config: N/A 


"NO" 
"YES" 


0.0 
1.0 


0 
1 


PRI 


Read: [view] 
Write: N/A 
Config: N/A 


"LOW* 
"MEDIUM'* 
"fflGH" 
(priority of Nth 
alarm) 


2.0 
1.0 
0.0 


2 
I 
0 


PRIAD 


Read: [view} 
Write: [alarm] 
Config: N/A (init 0) 




0.0..3.0 


0.,3 


TAG 


Read: [view] 
Write: N/A 
Config: N/A 


Full reference 
path for Nth 
alarm attribute. 


N/A 


N/A 



User-Level Alarm C:onsolidation is achieved using an "Alarm Banner** in the graphical user 
intei^. Alarm consolidation is supported for a "current user". Each user is granted authority over one or 
more Plant Areas. The "current user** alarm consohdation provides the ability to prcsait the highest priority 
alarms of the set of Plant Areas cunentty in the user's span of control A pre-defined '^attribute container** 
carists, named 'THISUSER^ whidi supports the ALARMS[N] Attribute. Users optionally construct displays 
referencing 'TfflSUSER/ALARMSfNJ.field* to allow quick access to the highest priority alarms for the 
"current user". 

A ustt Enables and Disables Alarms if granted an alarm privilege. With the alarm privilege, a user 
m^ Enable or Disable a single Alarm Attribute by writing to the .ENAB field (e.g. writing TRUE to 
•AREAl/nC101/HL\LMENAB'. Each Alarm Attribute in the process control system includes a single 
Enable/Disable conditioa When one user changes state. Alarms are Enabled/Disabled for all users. With 
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the alarm privilege, a user Enable or Disable all alanns in a SP88 Module Alann by writing to the 
.ENAB field of the ALARMS Attribute (e.g. writing TRUE to *AREA1/FIC101/ALARMS.ENAB'). 
Disabling Alanns at the Module level overrides, but does not overwrite, individual Alarm's ENAB 
condition. When Alarms are Enabled at the Module level. Alarm processing determined by the individual 
Alarm's .^AB condition is restored. 

Each SPS8 Module in the system includes a single Enable/Disable condition. When one user 
changes state, all Alarms in that Module are Enabled/Disabled for all users. 

A user having an operate privilege can Acknowledge Alarms. With the operate privilege, a user 
Admowlcdgcs a single Alarm Attribute by writing FALSE to the .NALM field (e. g. writing FALSE to 
*AREA1MC10I/HIALMNALM'). Attempts to write TRUE to the .NALM are ignored. EachAhirm 
Attribme in the process contn)lq^stem has a single Admowiedgecondi When one user changes state. 
Alarms are Adcnowledged for aU users. With the operate privilege, a user may Acknowledge all alarms in a 
SP88 Module Alarm by writing FALSE to the .NALM field of the ALARMS Attribute (e.g. writing FALSE 
to •AREAl/nClOl/ALARMS.NALM'), an operation which has substantially the same effea as writing 
FALSE to tiie .NALM field of aU Alarm Attributes in the Module. Attempts to write TRUE to tiie .NALM 
are ignored. 

A user having an alarm privilege can change alarm priori^. With the alarm privilege, a user may 
change PRI on a single Alarm Attribute by writing to die .PRI field (e.g. writing Oto 
•AREAl/nciOl/mALM PRI' to make it a "HIGir priority alarm). Since Auto Acknowledgment behavior 
is determined by Alarm Priority, changing Alarm Priority may cause an Alarm to change adaiowlcdgment 
status. For example, changing from a priority wiUi AutoAdk FALSE to a priority with AutoAdc TRUE 
should cause unacknowledged alarms to be acknowledge. Also, changing from a priority with AutoAck 
TRUE to a priority witii AutoAck FALSE should cause acknowledged alarms to become unacknowledged. 

Each Alarm Attribute in the system has a single .PRIconditioa When one user changes state, .PRI 
is changed for all users. 

Wuh the alarm privilege, a user may adjust the effective priority for aU alanns in a SP88 Module 
Alarm by writing to tiic .PRIAD field of the ALARMS Attribute. For example, a user writing 1 to 
•AREAl/nC101/ALARMS.PRIAD' increases tiie current Alarm Priori^ value, tiierd>y diminishing the 
annuciation behavior, by one "step" so tiiat fflGH priority becomes MEDRJM priority, and LOW priority 
becomesLOG. The user only sets PRMD to positive nmnbers and tiicrefore is onty used to dim^ 
annundationbehavior. Setting PRIAD to 0 reestablishes the "normal" priorities deterininedp^^ 
Attribute. EflSxaive alarm priorities are not adjusted -Ijclow^ LOG, Since Auto Acknowledgment behavior is 
determined by Alarm Priority, dianging PRIAD at tiic Module Icvd may cause individual Alarms to change 
acknowledgment status. 
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Each SP88 Module in the system has a single ,PRIAD value. When one user changes state, aU 
Alarms in that Module are affected for all useis. 

Alarms are viewed using a disphy under a standard FIX^ Alarm Sunmia^ The FUC™ graphic 
and display program, which is madceted by Inlelhition of Norwood, MA, is well known in the confuting 
arts. The FIX~ Alarm Summary Link is the prinmy method to view filtered and s^ 
Alarms, All capabilities of the Alarm Summary Link are supported, with the following exceptions or 
extensions. First, a "Tagname" cohmm shows the process control system Attribute rcf^^ 
the Field name, for the Alarm Attribute (e.g. •AREALnCIOl/FOALRM'). Second, a "Description" 
contains a user-configured string that is constracted at the time the Al^ 

captures the value of up to two Attributes at the point the Alarm was first detected Only one "Alarm" per 
^ '•Tag" is possible so that multiple Alarms may be shown for each SP88 Module in the Alarm Summary. 
Third, a "Time Last" entry contains the time of the last state transition for the Active Alarm, which could be 
the time of acknowledgement, or the tune of the last transition between Active/Inactive for an 
unadmowledged alarm. Fourth, a "Node" column entry, which shows FIX SCADA Node source for the 
Alarm, is meani ngless for process control system Alarms so that a by Area Filter and Sort feature arc lost 
Fifth, all Alarms are mapped into one of the FIX Alarm ^rpes to achieve for^ound color based on the 
Alarm Type. 

A user can access an Alarm State Transition Joumaling record. Alarm state transitions are recorded 
in the Event Journal assigned to a Plant Area, All alarm state transitions shown in FIGURE 41 are recorded 
in the Event Journal, including transitions between the Inactive/Unadc'd 41 14 and the Activc/Unack'd state 
4118. Thus an operator viewing the LAALM field in displays or alarm summaries does not sec transitions 
between Active/Inactive states for unacknowledged alarms, these transitions are recorded in the Event 
JouraaL 

Event journal entries for alarm state transitions include: (1) a timestamp of the alarm state transition 
as determined by the device (e.g. controller) detecting the alarm condition, (2) an "alarm" event type which 
distinguishes from other event journal entries, (3) a user-defined alarm category. (4) a current alarm priority, 
(5) an alarm word string as configured in the ^em Alarm Type table, (6) an new alarm state, (7) an 
amibutB leferoioe string or path for the alarmed attribute, and (8) a description string assembled from the 
descr^on string configured in the Alarm Type table, with the configured (up to two) Attribute values 
inserted in the string. 

A Event Journal browser application presents data in a manner shown in TABLE IV, generaUy 
sorted by timestamp and filtered on event type "ALARM" and attribute reference string = 
"nClOl/PIDl/HLMAr): 



TABLE IV 



DA-MO-YR 


ALAR 


PROC 


MEDI 


HIG 


ACTAJNA 


FIClOl/PIDl/HI 


value 96.2 


10:11:04.4 


M 


ESS 


UM 


H 


CK 


ALM 


limit 95.0 
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DA4^0YR 
10:11:18.6 


ALAR 
M 


PROC 
ESS 


MEDI 
UM 


me 

H 


INACT/UN 
ACK 


FIClOl/PIDl/ffl 
ALM 


Value yj, / 
limit 95.0 


DA-MO-YR 
10:13:45.6 


ALAR 
M 


PROC 
ESS 


MEDI 
UM 


fflG 
H 


DISABLE 
D 


nClOl/PIDl/ffl 
ALM 


value 93, 1 
limit 95.0 


DA-MO-YR 

10:22:00.1 


ALAR 
M 


PROC 
ESS 


MEDI 
UM 


me 

H 


ACT/UNA 
CK 


nCIOl/PIDI/ffl 
ALM 


value 95.8 
limit 95.0 


DA-MO-YR 
10:22:20.9 


ALAR 
M 


PROC 
ESS 


MEDI 
UM 


fflG 
H 


ACT/ACK 


ncioi/piDi/m 

ALM 


value 95.9 
limit 95.0 


DA-MO-YR 
10:27:59.4 


ALAR 
M 


PROC 
ESS 


MEDI 
UM 


fflG 
H 


CLEAR 


nClOl/PIDl/HI 
ALM 


value 94.0 
limit 95.0 



Atom mte transMoBS waits in the Evm Journal are di^ 
although operator changes cause conesponding alaim state changes. For example, as shown in TABLE V 

follows: . 



TABLE V 



DA-MO-YR 
10:13:45,9 


CHAN 
GE 


aoN 

ES 


A 




HClOl/PIDl/fflALM. 
ENAB 


new value = 
FALSE 


DA-MO-YR 
10:22:00.1 


CHAN 
GE 


aoN 

ES 


A 




nClOl/PIDl/fflALM 
ENAB 


new value = TRUE 


DA440-YR 
10:22:21.3 


CHAN 
GE 


CJON 

ES 


A 




nCIOiyPIDl/fflALM. 
NALM 


ALARM/ACK 


DA-MO-YR 
15:28:59.4 


CHAN 
GE 


BSMI 
TO 


A 




FICIOI.ENAB 


new value 
FALSE 



The Alann Attiibtites are configured, thereby setting the Alann behavior and presentation, using the 
described sequence of operations. First, an "Alarm Types" Table and an "Atorm Amumciation" Table are 
configured. Second, in an optional step, the user-defined alarm conditions arc configured, setting the 
boolean Attributes. Third, Alarm Attributes are created to reference the boolean Attributes, thereby 
identifying the System "Alarm Type", priority, and tiie like. Fourth. Module "instances" are created based on 
Module Definitions that contain Alarms. Fifth, a presentation of Alarm information is inserted into displays 
(pictures) via database links, dynamic color links, and Alarm Summaiy links. Sixth, the "Alarm Types" and 
"Alarm Annmuaation" TaUes aie configured. 

nie "Alarm Type" table has several fimctions, including (1) acting as a system (Site) wide common 
resource which defines a common Alarm presentation behavior to speed tiie Alarm configuration process for 
each Alarm, a) encouraging standard alarm messaging in Summaries and History Journals to improve qnciy 
and analysis tiiat information, (3) m^^ing alarms into FIX Alarm States. 

The -Alarm Types" Table contains cohmms including an Alarm 1>pe. an Alarm Woid. a category 
and a description string oohnmt The Alarm T^cohmm contains a brief description of flie Alarm Type; 
whichisnsedtoselectthe appropriate Type whencnating an Alarm Attribute. The Alarm Word cehmm 
inctodes a suing Uiat is retutned when reading the A_CU ALM or A_LAALM Fields when the Alarm is 
Artive. The category cohmm describes a user defined word recorded in the Event Journal used to help 
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filter/sort queries. The deso^on string appears in the Alarm Suimnaxy link ai^ 
holders for Attribute value substitution at Alarm Detection time. 

The "Alarm Tapes'* Table de&uU content is shown in TABLE VI as follows: 



TABLE 




COMM 



:^>:■.p::■^^^?;r^?S/3:^^x¥^:#-^«Mf.^ 



OCD 



lOF 



FLT 



OVER 



UNDER 



ERROR 



NEW 



ANY 



CFN 



COS 



Him 



LOLO 



RATE 



mm 



mmmimmm 



LOW 



DEV 



nipOTddtoed) 



OK 



(user defined) 



INSTRUME 
NT 



INSniUME 
NT 



INSTRUME 
NT 



SYSTEM 



INSTRUME 
NT 



INSTRUME 
NT 



SYSTCM 



SYSTEM 



SYSTEM 



PROCESS 



PRCKIESS 



PROCESS 



PROCESS 



PROCESS 



PROCESS 



PROCESS 



PROCESS 



Communication Error 



Open Circuit Detected 



General I/O Faihue 



Floating Point Error 



Over Range Value V<P\ 



Under Range Value %P1 



Statistical Alarm Type %P1 
Value %P2 



New Alarm Value %P1 



Any Alarm Value %PI 



Change From Normal Value %P1 



Change of State 



High High Alarm Value %P1 
Limit %P2 



Low Low Alarm Value %P I 
Limit %P2 



Rate of Change Rate %P1 Limit 
%P2 



High Alaim Value %P1 Limit 
%P2 



Low Alarm Value %P1 Limit 
%P2 



Deviation Alarm Target %P1 
Actual %P2 



Normal State 



(user defined) 




Standard alarm types match the alarms types supported in FDC^. 

The "Alarm Annunciation^ table is a system (Site) wide common resource which furnishes a 
conmum definition of Alarm annunciation beha^or to speed the Alarm configuration process for each 
Alarm 



The "Alarm Types'* Table contains the columns including an Alarm Priority, an Auto 
10 Acknowledgement, a WAV file and a PC speaker frequency cotomn. The Alarm Priority designates the 

Alarm priority word (fflGH/MEDIUM/LOW/LOG). TTic Auto Acknowledgment column contains a YES/NO 



^ Probably no reason for this to be configured, or even visible to the user. 
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value indicatiiig if alanns of this priority should be automaticalty acknowledged whca detected atidproviding 
an opportumty to make less impoitam alarms less "distracting^^ The WAV file contains a filename of a NT 
compatible .WAV file which is played (looping) when an Alarm is detected (within the scope of the current 
user) at a Workstation with a sound card. Omitting this file name indicates that no WAV file should be 
pl^ed for alanns with this priority. The PC Speaker fiiequency seAs a value used to play a tone on the PC 
spcakeri^1ienanAlarmisdetccted,witlun the scope of the current user, at a Workstation without a sound 
card. A vahieofO indicates that the PC q)eaker should not be used for alaiins with this piio Ifa.WAV 
file and a nonO speaker fiequ^iqrare specified for the same alarm priority, the PC speaker is used only if no 
sound card is present 

The •'Alarm Annunciation" Table default content is shown in TABLE Vn as follows: 

















NO 


ALRMfflGRWAV 


7 






NO 


ALRMMED.WAV 


? 




^^^^^^ 


YES 


ALRMLOW.WAV 


7 






YES 







A user attaches Alarm (behavior) to boolean Attributes by creating Alarm Attributes according to 
the SPSS Module Definition which reference another boolean Attribute in the same Module. 

Ausercreatean Alarm Attribute by entenng: (1) a target Attribute by path or by drag-and-drop, for 
example, (2) a boolean Attribute defining the alarm condition, (3) an Alarm Type selected from the system- 
wide list of Alarm Types, (4) an Alarm Priority (High/Medmm/Low/Log), (5) an Initial Alarm Enable 
condition (YES/NO), (6) an Invert Input (YES/NO), (7) an optional Name of Attribute having a value to be 
substituted for %P1, (S) an optional Name of Attribute having a value to be substituted for %P2. 

Items 7 & 8, the Attribute names, are restricted to Attributes in the same SPSS Module and are 
spcafLcd as "module lelarive'' attribute references (e.g. "SP" and "PIDl/PV" rather than 'TICIOI/SP'* or 
-nClOl/PIDl/PV". 

The user also creates Module "instances'* based on Module Definitions that contain Alarms. When 
a Module instance is created, all Alarm behavior specified in the Module Definition applies to the Module 
instance. The .PRI and .ENAB fields may be overridden on Alarra'd Attributes when the Module instance is 
created. For example, if for an Alarm Attribute naincd *ffl(HILIMrrED\ PRI is MEDI^ 
Module Definition is constiucted, thai when the Module instance is created, 'HIGHLIMrrED,PRI' may be 
overridden to be LOW for this instance. 

Alarms are supported for Device/Subsystem Attributes in Omtrollers. Attributes are defined for 
devices and device subsystems to provide access to information about the operation of the control system and 
connections to other systems. The Attributes are accessible via diagnostic tools and via pre-defined or us^- 



W098/3d335 



-77- 



PCT/US98/01573 



in 



defined displays. It is valuable for some of these Attributes, especially "consolidation" Attributes, to 
partidpaie in the Alann system to draw attention to abnonnal conditions in the control system. 

UscfS create Control Modules (instances) to implement a desired "Device Alarm" strategy for 
Controllers and Subsystems, including processor, communicaUons, I/O, redundancy, and the like. 

Using Function Blodc algorithms, the Device/Subsystem Attributes are accessed most efficiently 
the same device, bm also sqjported for other ControUecs and Workstati^^ Device and SiAsystem 
Attributes are used as inputs to Function Blocks, vrtudi then can be confix 

these Attributes, converting these values to boolean Attributes. AlarmAttributes then reference the boolean 
Attributes. In general, the foil algorithm definition capability of the Function Block system is used to buUd 
simple or complex Device Alanning schemes. 

A number of the pre-defined Alarm Types, wliich are consistent with HX™ alarm types, arc 
suitable for distinguishing "Device Alarm" presentation and behavior Pre-defined Control Module 
Definitions are supplied providing fairiy comprehensive Device Alarm "modules" for ControUens, and each 
type of I/O system. Users optionally disable or extend Uiese standard modules. 

Users m^ elect several strategies for placing Device Alarm modules in Plant Areas inchiding a 
smalUsystera strategy, a "segregation^ strategy and a-partitioned responsibility" strategy, for example. In the 
small system an "all in one" strategy is imposed in which tiie Plant Area concept is not applied. One or 
more Device Alarm Modules in each Controller form an integrated presentation of Device and SP88 Module 
alarms. In tiie segregation strategy a separate Plant Area is designated which has all Device Alarm modules 
from all Controllers. The segregation strategy enables Area filtering/sorting on Alarm summaries, allowing 
Operators to focus on SP88 Module Alarms and Process/Maintenance Engineers to focus on Device Alarms. 
The partitioned responsibility strategy is used when the system becomes large enough to control scope of 
responsibiUty by Plant Area. Device Alam Modules are placed in tiie same Plant Area as tiie SPSS modules 
impacted by tiie Device Alarm Modules. The partitioned responsibUity strategy forms an integrated 
presentation of Device and SPSS Module alarms for Plant Areas witiiin scope of responsibitity. 

Alarms are si^orted for Device/Subsystem Attributes in Workstations. User-initiated applications 
such as Draw, View, engineering tools, and tiie like individually present infonnation about abnonnal 
conditions or eirois encountcarcd, in tiie appropriate context Workstation Services which are activated on a 
woikstation before a user logs on and continue to run tiirough log-oflWog-on cycles) implement a technique 
for drawing attention to problems, even for an unattended Workstation. In one embodiment, Woricstation 
Services are monitored Iqr Device Alarm Modules executing in one or more ControUers. TheServices 
constnia a set of status and integrity Attributes, which are accessed by Controller(s) nmning instances of 
Device Alarm Modules wMdi control tiie user-defined Device Alanning^ Pre-defined Control 
Module Definitions are supplied providing feiity conq)rchensive Device Alairo "modules" for Woikstations. 
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and each major Service (e.g. commnnications. hisioiy journal, etc.) Users may disable or eideiul these 
standard nuxlules. 

In one embodiment of the process control system, event conditions that are not afforded "Alarm" 
status are given a priority of «LO<r. IX)G Alarms are not consoKdated in ALARMS Attributes, do not 
appear in the Alarm Sununaiy. do not provide aiuUble annunciation of state changes, and appear in Event 
Journals as type "EVENT" rather than type "ALARM-. In other respects a LOG priori^ Alarm operates as 
raGH/MEDIUM«X)W priority Alarm so that an event (1) is enabled/disabled indtvidualiy. (2) is disabled at 
the Module level with other alarms. (3) individual Alarms can be "tumed into Events" by changing their 
priority to "LOG" (writing 3 to .PRI). 

By setting PRIAD at the Module level, one or more levels of Alarms can be converted to Events 
(c. g. writing 2 to .PRIAD drops aU Alarm priorities in the Module by 2 steps; HIGH prioiily becomes LOW. 
MEDIUM and LOW priority become LOG. LOG remains LOG). Setting .PRIAD to 3 forces aU Alarms in 
the Module to become "Evems". CUALM. LAALM. NALM field supported to displiQr current status (even 
blinking if unadced). 

LOG events also (4) may imrert the input boolean, to reverse the sense of the OK event condition for 
usage to log changes in stale of Discrete Inputs, (5) may add user defined "alarm words" to the Alarm Types 
table to give event conditions useful names, (6) record aU state changes for a LOG priority alarm in the Event 
JoumaL 

User selecuble "intensities" of system event detection (e.g. "debug intensity", "normal intesi^', 
"shutdown intensity") are configured in Control Module algorithms based on the setting of a user defined 
"intensity" Attribute. Systan Events arc thus aligned with one (or perhaps more) Plant Areas, and so 
enabling the Event Journal on a Woricstation for one or more Plant Areas automatically sets the destination 
for all "System Event" records. 

A user changing an Attribute or invoking a method on a System Object is considered an event and 
is recorded in the appropriate Event Journal Changes to control hierarchy (Control Module, Equipment 
Module. Plant Area, etc.) Attributes are recorded in the Event Joumal(s) designated for that Plant Area. 
Changes to Device/Subsystem Attributes arc recorded in the Event Joumal(s) for the "primary Plant Area" 
designated fw that Device. 

Referring to nOURE 42. a context diagram shows a context for di^niqg an alarm evcm with 
respect to a control module. An Alarm appears in a "Plant Area scope" active alarm list presenlatioa A 
composite module (CM) instance 4210 includes a PID fimcUon block 4212. an output attribute 4214 and a 
high alarm attribute 4216. A user, such as a configuration engineer, selects the compositB module 4210 for 
editing and selects "add alarm" 4220 on Attribute "HIHr . The user also selects the event priori^ definition 
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named "Advisofy" 4232 and the event ty^ definition named "HIALARNT' 4234. The user then saves the 
changes to the conuol module 4210. 

Referring again to FIGURE 40, alarm and event management is described. Alarms and user- 
defined "evenu" which are configured as LOG priority Alarms introduce multiple behaviors into the process 
control system. 

A special kind of RtAttributc, hereafter called RiAlannAttribute 4034, has a distinct "data type" 
supporting Alann specific fidds such as CUALHNALM, and the lik^ Read 
access to the fields allows presentation of the state of individual Alarms. Write access to selected fields gives 
an ability to Acknowledge Alarms, and change certain alarm behaviors. 

Several characteristics of Alarm behavior, such as Disabled and AUTO ACK behavior, m^ be 
overridden on-line at the SP88 Module level Reverting to the individual Alarm conditions of 
Enabled/Disabled and NoAutoAck/Auto Ack occurs when the Module level overrides are removed. The 
changing of Module level overrides should "immediately" impart individual Alarm sutes. Thus changes on 
the Module level override force re-evaluation of all Alarm states within the module under the new conditions. 

Active alarms are consolidated at the Module (RtModule 4030), Plant Area (RtPlantArea 4010), and 
User Session so that the "highest priority alarms" at each of the levels may be presented. This consolidation 
is accessed through the ALARMSQ Attribute supported by Module, Plant Area and User Session objects. 

FIX^M Alarm Summary Links are used in FIX™ pictures (displays) to present a list of "current" 
alarms. The content for the Alarm Summary Link is maintained by the ALMSUM.EXE process (which shuts 
down when FDa" shuts down, and FDC™ shuts down whenever an NT user logs otf . and NT users log off 
to allow a new user to "log in".) Thus the system must both "prime" the ALMSUM process with all current 
alarms (subject to current user responsibility scope) to get it started when an new user logs-on, and it must 
feed the Al^SUM process information about new alarm occurrences, and alarm acknowledgments so a vp- 
to-date summaiy can be presented. 

All alarm sute transitions are directed to the appropriate Event Jcumal(s) (RtEvcnUoumal 4020) for 
the Plant Area which "contains" the RtAlarmAltribute 4034. Multiple Event Journal targets are supported, 
so that a complete Event Journal can be reconstructed if one workstation running one of the Event Journals is 
off line for a period of time. 

Audible annunciation of Alarm entry state transitions executes on workstations doing Alarm 
Summarization (feeding the FIX ALMSUM.EXE process). Audible annunciation may consist of a 
continuous tone (user configured frequency) on the PC speaker, and/or a continuous (looping) .WAV file 
played on a compatible sound card installed in the PC. A program is executed to turn off both the speaker 



wo 9806335 



-80. 



PCT/US98/01573 



and the ficmnd cani, thus the sound 

ICOU in the program Gioiqi if FIX VIEW is not nmning. 

Referring to FIGURE 43, an objca communication diagram Ulustrates a method for performing an 
attribute write operation that evokes an "in alarm" sutus. 

Previous to the attribute write operation, a RtAlannAttributc has been configured and instaUed, 
al^ are ENABLED at both the Attribute and the Module level, a^ 
Attribute and the Module level, and the current Alann state is 'Inactive/AcJmowledged''. 

The ^wite Attribute" method causes the state of an Alarm Attri Hic 
alarmfiddsofthe Alarm Attribme are updated to reflect the new Ala^ An event occurrence record is 
constructed, and sent to the Module. Plant Area, and workstation aj^lications (Alarm Summary, Event 
Journal), as needed. 

When the attribute write operation is complete, the current Alarm state is 
« ActrveOJnadcnOTsiedged-, the active alarm has been recorded by the Module, the event occurrence record 
has been constructed, and has been queued for transmission to devices monitoring this Plant Area in this 
Device. 

In a step 4310 of the write attribute method, RtAIarmAttribute receives a writeAttribute, which 
causes a state transition in the boolean Attribute to enter the alarm stale. In step 4312, RtAIarmAttribute 
gets alarmDisable status fiom the RtModule containing RtAIarmAttribute so that both Attribute and 
Module Alarm behavior are ENABLED. In step 4314, RtAIarmAttribute gets alarmAutoack status from 
the RtModule containing RtAIarmAttribute so that for both Attribute and Module Alarm AUTO ACK is 
DISABLED. In stq> 4316, RtAIarmAttribute computes a new alarm state, the "ActivcAJnacknowledged" 
state and reads the prototype event descriptor string from RtEventTypeDefinition using AlarmType as an 
index. In step 4318, RtAIarmAttribute constructs the descriptionString for the RtEventOccuraceRecord, 
reading current attribute values fiom the containing RtModule, if necessary. In step 4320, 
RtAIarmAttribute constructs a new RtEventOccorenccRecord. Since a new alarm is created, 
RtAlannAttributc tells its containing RtModule to addEventOccorrcnce in step 4322. In stq> 4324, 
RtModule tells its RtActiveAlarmlist to addEventOccurrcnce, adding a new entry to the list and 
returning a handle by which the entry can be accessed in the future. TTiis handle is ultimately stored by 
RtAIarmAttribute. In step 4326, RtModule sends the RtEventOccurenceRecord to the RtPlantArea of 
RtModule via recordEventOccurrcncc. In step 4328, RtPlantArea teUs its RtAreaEvcntLog to addEvcnt, 
RtAreaEvcntLog sees that at least one woricstation client has registered an interest in receiving EvcntLog 
recofds, creates an RtEvcntLogRecord from the RtEyentOccur^nccRecord, and queues the 
RtfiventLogRecord, thereby destroying the RtEvartOccureac^lccord. 
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Also rcfcning to FIGURE 43. the object communication diagram is also appUcable to 
Actaiowlcdgcmem of an Alann. causing the cnnemalam "Activc/AdaiowIcdgc<r. The new 

alann state for the existing alann is rccoided by the Module, a new event occurrence record is constructed, 
and is been queued for transmission to devices monitoring this Plant Area in this I>cvice. The method 
includes application of the ^vritc Attribute" method (writing FALSE to the NALM Field) to cause the state 
of an Alarm Attribute to be acknowledged Alarm Gelds of the Alarm Attribute are i^ted to reflea the 
new Alarm state. An event occurrence record is constiucted, and sent to the Module. Plant Area, and 
woikstation applications (Alann Summaiy, Event Journal) as needed. 

In step 4310, RtAlarmAttribnte receives a writeAttribnte, causing the NALM Fidd to change state 
to FALSE. In step 4312, RtAlarmAttribnte gets alarmDisable status from the RtModnle containing 
RtAlarmAttribute so that both Attribute and Module Alarm behavior are ENABLED. In step 4316, 
RtAlarmAttribute computes a new alarm state, the "ActiveAJnacknowledged" state and reads the proto^ 
event descriptor string from RtEventTypeDefmition using Alarmiype as an index. In step 4318, 
RtAlarmAttribute constructs the dcscriptionString for the RtEventOccurenceRecord, reading current 
attribute values from the containing RtModule, if necessary. In step 4320, RtAlarmAttribute constructs a 
new RtEventOccurenceRecord. Since an existing alarm is updated, RtAlarmAttribute tells the RtModule 
containing RtAlarmAttribute to updatcEventOccurrence. identi^ng RtModule by the handle returned 
when from updateEventOccurrence in step 4322. In step 4324, RtModule tells RtActiveAlannUst to 
updateEventOccarrcnce. thereby voting the existing entiy in the list In step 4326. RtModule sends the 
RtEventOccurenceRecord to the RtPlantArea of RtModule via recordEventOccnrrence. In stq) 4328. 
RtPlantArca tells its RtAreaEventLog to addEvcnt, RtAreaEventLog sees that at least one workstation 
client has registered an interest in receiving EvcntLog records, creates an RtEventLogRecord from the 
RtEventOccurenceRecord, and queues the RtEventLogRecord, thereby destroying the 
RtEventOccurenceRecord. 

Also referring to FIGURE 43, the object communication diagram is also applicable to 
aknowledgemcnt of clearing of an alarm condition, in which the **write Attribute" method causes the state of 
an Alarm Attribute to go out of the alarm sUte. The alarm fields of the Alarm Attribute are updated to reflect 
the new Alann state and an event occurrence record is construaed and s«it to the Module, Plant Area, and 
workstation applications (Alarm Summaiy, Event Journal) as needed. When the write Attribute method is 
con^ilete, the current Alaim state is "Inactive/Adcnowledged". The current alarm information for this alarm 
has been removed by the Module. A new event occurrence record has been constructed and queued for 
transmission to devices monitoring this Plant Area in this Device. 

In step 4310, RtAlarmAttribnte lecdves a writeAttribnte, which causes a state transition in the 
boolean Attribute to go out of the alarm state. In step 43 12. RtAlarmAttribnte gets fliarmniy^bl? status from 
the RtModule containing RtAlannAttribntc so that both Attribute and Module Al^ 
ENABLED. In stq> 4316, RtAlarmAttribute computes a new alarm state, the "Active/Unacknowledged" 
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state and reads the prototype event descriptor string from RtEventTypeDefiiiitlon using Alarmiypc as an 
index. In step 4318. RtAlarmAttributc constructs the dcscriptionString for the RtEventOccnrenceRecord. 
reading current attribute vahics from the containing RtModule, if necessary. In step 4320, 
RlAUnnAttribate constructs a new RtEventOccurenccRecord Since an existing alarm is cleared, 
RtAlarmAttribute teUs the RtModole containing RtAlarmAttributc to updateEventOccnrrence. 
idoiti^ RtModule by the handle returned when from updatcEventOccurrence. In stq) 4322. RtModule 
tdls RtActiveAiarmlist to updateEventOcciimnce. theieby updating the existing entiy in the list In step 
4326, RtModule sends the RtEventOcourcnceRecord to the Rff lantArea of RtModale via 
recordEventOccorrence. In step 4328, RtPlantArei tells its RtAreaEventLog to addEvent. 
RtAreaEventLog sees that at least one woikstotion client has registered an interest in receiving EventLog 
records, creates an RtEventLogRecord from the RtEventOccuraiceRecord, and queues the 
RtEventLogRecord. thereby destroying the RtEventOccurenceRecord. 

Also Kfcrring to FIGURE 43. the objea communication diagram is also applicable to disablement 
of an alarm by causing the ENAB Field of an Alarm Attribute to become FALSE, The alarm fields of the 
Alarm Attribute are i^ed to leflea the new Alarm state and an cvem oc^ 
and sent to the Module, Plant Area, and wmkstation appUcations (Alarm Summary, Event Journal), as 
needed Following the disablonent of an alarm, the current Alarm state is "Inactive/Adaiowiedged" and the 
ENAB field is FALSE. The current alarm information for this alanm has been removed by the Module. A 
new event occurrence record (alarm DISABLE) has been constructed and is queued for transmission to 
devices monitoring this Plant Area in this Device, 

In step 4310, RtAiannAttrittiute receives a writeAttribute, which causes the ENAB Field to 
become FALSE. In step 4316. RtAlarmAttribute computes a new alarm state, the 

"ActiveAJnacknowledgcd" state and reads the protoQiie event descriptor string from RtEventTypeDefinition 
using AlarmType as an index. In step 4318. RtAlarmAttribute constructs the dcscriptionString for the 
RtEventOccurenceRecord, reading current attribute values from the containing RtModule, if necessary. In 
step 4320, RtAlarmAttributc constructs a new RtEventOccurenceRecord^ identifying this evem as an 
alarm disable event. Since the alarm is disabled when previously active, this event is the clearing of an 
existing alarm, RtAlarmAttribute tells the RtModule containing RtAlarmAttribute to 
dearEventOecurrence, identifying RtModule by the handle returned when from clearEventOccurrencc. 
In step 4322. RtModule tells RtActivcAlannUst to clearEventOccurrencc, thereby removing the existing 
entry fixmi the list In step 4326, RtModule sends the RtEventOccurenceRecord to the RtPiantArea of 
RtModale via record£ventOccunr«nce. In step 4328. RtPiantArea tells its RtAreaEventLog to addEvent, 
RtAreaEventLog sees that at least one workstation cHcm has registered an interest in receiving EventLog 
records, creates an RtEventLogRecord from the RtEventOccurenceRecord. and queues the 
RtEventLogRecord, thereby destroying the RtEventOccurenceRecord 
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Also rcfeiTing to FIGURE 43, the object commuiiicatioii diagram is also applicable to enablement 
of an alann by causing the ENAB Field of an Mann Attribute to become TRUE. Prior to enablement of an 
alaim, the cunent state of the boolean Attribute shows the alann would be Active if Enabled, AuioAck is 
False at the Attribute and Module level. Thealannfieldsof the Alann Attribute are updated to reflect the 
new Alarm state and an event occunence record is constructed, and sent to the Module, Plant Area, and 
workstation applications (Alarm Sununaxy, Event Journal), as needed. FoUowing the disablement of an 
alann, the current Alann state is ••ActiveAJnacknowledged*' and Thecurrent 
alarm infonnation for this alarm is stored by the Module. A new event occurrence record (alarm 

Active/Unacknoiiidedged) has been constructed and is queued for tnmsmisaon to dc^ 
Plant Area in this Device. 

In step 4310, RtAlarmAttribute receives a writeAttribute, which causes the ENAB Field to 
become TRUE, In step 4312, RtAlarmAttribute gets alarmDisable status from the RtModule containing 
RtAlarmAttribute so that both Attribute and Module Alarm behavior are ENABLED. In step 4314, 
RtAlarmAttribute gets alarmAutoack status from the RtModule containing RtAlarmAttribute so that for 
both Attribute and Module Alann AUTOACK is DISABLED, In step 4316, RtAlarmAttribute computes a 
new alann state, the "Active/Unacknowledged" state and reads the prototype event descriptor string from 
RtEventTypeDcfmltion using AlarmType as an index. In step 4318, RtAlarmAttribute constnicts the 
descriptionString for the Rt£ventOccurenccRecord, ceading cunent attribute values from the containing 
RtModule, if necessaiy. In step 4320, RtAlarmAttribnte constructs a new RtEventOccurenceRecord. 
Since the alarm is new. RtAlarmAttribute tells the RtModule containing RtAlarmAttribute to 
addEventOccnrrence, identifying RtModule by the handle returned when from addEventOccurrence. In 
step 4322, RtModule tells RtActiveAIarmList to addEventOccurrence, thereby adding a new entry to the 
list In step 4326, RtModule sends the RtEventOccurenceRecord to the RtPIantArca of RtModule via 
recordEvcntOccurrencc. In step 4328, RtPlantArea tells its RtAreaEventLog to addEvcnt, 
RtAreaEventLog sees that at least one workstation client has registered an interest in receiving EventLog 
records, creates an RtEventLogRecord from the RtEventOccurenceRecord, and queues the 
RtEventLogRecord, ther^ destroying the RtEventOccurenceRecord. 

While the invention has been described with reference to various enibodhnents; it will be understood 
that these cmbodiraents arc illustrative and that the scope of Uie invention is not limited to thent Many 
. variations, modifications, additions and improvements of the embodiments described arc possible. 
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WE CLAIM: 



1 1. A process control system (100) for controlling a plurality of field devices of multiple different 

2 field device types including smart*^ field devices (132) and non-smart-type field devices (136), the process 

3 control system comprising: 

4 a plurality of distributed controllers ( 1 10) coupled to the field devices; and 

5 a software system including a plurality of control modules (440) selectively installable and operative 

6 on ones of the plurality of distributed controllers, the software system for communicating 

7 with the smart-type and the non-smart-type field devices and for controlling the smart-type 

8 and the non-smart-^pe field devices. 

1 2. A process control qrstem according to Claim 1 wherein the software system fiirtherm^^ 

2 a configuration program for configuring the control modules and installing the control modules on 

3 the phirality of distributed controllers, the distributed controllers retaining the configuration 

4 until reconfigured 

1 3. A process control system according to Claim 1 wherein the plurali^ of control modules is 

2 configured into a communication services hierarchy including: 

3 a remote object communications (ROC) level for communicating messages between two control 

4 modules in a same controller and between two control modules in different controllers, and 

5 a low levd communications level for intcr&cing with communications hardware and transmitting 

6 messages across the communications hardware. 

1 4. A process control system (100) for controlling a plurality of field devices of multiple different 

2 field device types including smart-type field devices (132) and non-smart-type field devices (136), the process 

3 control system comprising: 

4 a plurality of distributed controllers (1 10) coupled to the field devices; and 

5 a plurality of control means selectively installable and operative on ones of the plurality of 

6 distributed controllers for, in combination, controlling the smait-type and the non-smait- 

7 type fidd devices. 

1 5. A process control system (100) comprising: 

2 a plurality of field devices of multiple different field device types including smart-type field devices 

3 (132) and non-smait-type field devices (136); 

4 a plurality of distributed controllers (1 10) coupled to the fidd devices; 

5 a workstation (102) coupled to the distributed controllers; and 
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a plurality of contral means selectively installable and operative on ones of the phiniUty of 

distributed controUcre for. in combination, conuolling the smart-type and the non-smart- 
type field devices. 

6. A computer program product conq)rising: 

a computer usable medium having computable readable code embodied therein including a process 
control software system for controlling a plurality of field devices of multiple different field 
device types inchiding smart-type field devices (132) and non-smart-typc field devices 
(136). the process control system (100) including a phirality of distributed oontroUers (1 10) 
coupled to the field devices, the executable program code including: 
a software system induding a plurali^ of control modules (440) selecttveJ^r installable and 

operative on ones of the plurality of distributed contiolleis; and 
a communication and control routine for communicating with the smart-^ and the non- 

smart-typc field devices and for controlling the smart-Qpc and the non-smart-lype 

field devices. 

7. A computer program product according to Claim 6, the executable program code fimher 
conqnising: 

a user interfiice (300) for interfacing with a user, wherein: 

the smart-type and the non-smart-type field devices operate in compliance with defined bus-based 
architecture standards and the software system performs smart-type control operations and 
non-smart-^ control operations transparent to tiie user over the user interfece. 

8. A computer program product according to Claim 6 wherein the software system p^orms smart- 
type control operations using the plurality of control modules distributed on the pluraUty of distributed 
controllers operating ontiie smart-type field devices and non-smart-typc operations operating ontiie non- 
smart-type field devices independentiy, simultaneously and in parallel. 

9. A computer program product according to Claim 6 wherein the software system further includes: 
a configuration program for configuring tiie control modules and installing tiie control modules on 

the plmalify of distributed controllers, the distributed controllers retaining tiie configuration 
until reconfigured 

10. A computer program product according to Qaim 6 wherein tiic pluiality of control modules is 
configured into a communication services hiaarchy including: 

a remote object conununications (ROC) level for communicating messages between two omtrol 

modules in a same controller and between two control modules in different controllers, and 

a low level communications level for interlacing witii communications hardware and transmitting 
messages across the communications hardware. 
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1 1 1 . A process control system (100) for controlling a plurality of field devices of multiple different 

2 field device types including standard-protocol field devices (6) and non-standard-protocol field devices (12), 

3 the process control system comprising: 

4 a plurality of distributed controllers (1 10) coupled to the field devices; and 

5 a software system including a plurality of fimctton blocks (522) defined in a standard protocol, the 

6 function blodcs being selectively installable and operative on ones of tlw 

7 distributed oonlrollers for sdecthrdy controlling a standard-protocol field device and a non- 

8 standard-protocol fidd device. 

1 12. A process control system (100) for controlling a pluraliQr of field devices of mnltq)lc different 

2 field device types including standard-protocol field devices (6) and non-standard-protocol field devices (12), 

3 the process control system comprising: 

4 a plurality of distributed controllers ( 1 10) coupled to the field devices; and 

5 a plurality of control means selectively installable and operative on ones of the plurality of 

6 distributed controllers controlling, in combination, the standard-protocol field devices and 

7 the non-standard-protocol field devices. 

1 13. A process control system (100) comprising: 

2 a phuality of field devices of multiple different field device types including standard-i>rotocol field 

3 devices (6) and non-standard-protocol field devices ( 1 2); 

4 a plurality of distributed controllers (1 10) coupled to the field devices; 

5 a woricstation (102) coupled to the distributed controllers; and 

6 a software system including a plurality of function blocks (522) defined in a standard protocol, the 

7 function blocks being selectively installable and operative on ones of the plurality of 

8 distributed controllers for selectively controlling a standard-protocol field device and a non- 

9 standard-protocol field device. 

1 14. A process control system (100) for controlling a plurality of field devices of multiple different 

2 field device types including standard-protocol field devices (6) and non-standaid-protocol field devices (12), 

3 the process control system ccmqirising: 

4 aphuality of distributed controllers (110) coupled to the field devices; and 

5 a software system induding a plurality of function blocks (522) defined in a standard prcrtocoU the 

6 fimction blocks being selectively definable, crcalable, modifiable, and installable as a 

7 control module that is operative on ones of the plurality of distributed controllers for 

8 sdectivdy controlling a standard-protocol field device and a non-standard-protocol field 

9 device. 
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1 15. A process control system (100) comprising: 

2 a plurality of field devices of multiple different field device types including standard-pfotoco! field 

3 devices (6) and non-standard-protocol field devices ( 1 2); 

4 a plurality of distributed controllers (110) coupled to the field devices; 
^ a workstation (102) coupled to the distributed controllers; and 

6 a sofhme system induding a phirafi^ of fimction blocks (522) defined in a stand^^ 

7 function Mods being sdectiveiy definable, oeatable, modifiable, and installable as a 

8 control module that is operative on ones of the plurality of distributed controllers for 

9 selective^ controlling a standaid-inotocol field device and a non-standard-protocol field 
10 device. 

1 16. A process control system (100) for controlling a plurality of field devices of multiple diffeient 

2 field device types including standard-protocol field devices (6) and non-standard-protocol field devices (12), 

3 the process control system comprising: 

4 a phualiQr of distributed controllers (1 10) coupled to the fidd devices; and 

5 a phirality of controi modules (440) selectivdy definable, creatable, modifiable, and installable and 

6 operative on ones of the plurality of distributed controllers controlling, in combination, the 

7 standardfrotocol field devices and the non-standard-protocol field devices. 

1 17. A process control system according to any of Claims 1 1, 12. 13. 14. 15 and 16 fiirther 

2 comprising: 

3 a user interface (300) for interfacing with a user, wherein: 

4 the standard-protocol field devices and the non-standard-protocol field devices operate in 

^ con^liance with the defined Fieldbus ardiitccturc standard and the software system 

^ . . performs Standard-protocol control operations on standard-protocol field devices and non- 

7 standard-protocol field devices transparent to the user over the user intei&ce. 

1 18. A process control system according to any of Claims 11. 12, 13, 14, 15 and 16 wherein the 

2 software system fiutherindudes: 

3 a configuratimi program for configuring the fimclion blodcs and installing the fimction blocks on the 

4 plurality of distributed controllers, the distributed controllers retaining the configuration 
^ ^ until reconfigured. 

1 19. A process control system according to any of Claims 11, 12, 13, 14, 15 and 16 wherein the 

2 plurality of function blocks is confi£;ured into a communication services hierarchy including: 

3 a remote object communications (ROC) level for communicating messages between two fimction 

4 blocks in a same controller and between two fimction blodcs in differem controllers, and 
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a low Icvd comimmications level for interfacing with comiminications hardware and transmitting 
messages across the communications hardware. 

20, A computer program product comprising: 

a computer usabk inedium having computable n^adablc c^^ 

control system (100) for controlling a phuality of field devices of multiple different field 
device types induding standard-protocol field devices (6) and non-standard-protocol field 
devices (12). the process control system induding a plurality of distrflmted controUers (1 10) 
coiqjled to the field devices, the executable program code conqraang: 

a software system inchiding a plurality of function blodcs (522) defined in a standard protocol the 
function blocks being selectively installable and operative on ones of the plurality of 
distributed controllers for selectively controUing a standard-protocol field device and a non- 
standard-protocol field device. 

21. A process control system (100) comprising: 
a field device; 

a controller (1 10) coupled to the field device; 

a workstation (102) coupled to the oontroUer, the workstation including a user inters (300); and 
a software system implementing a control strategy for the process control system, the control 

strategy being selectively defined, created, modified, and apportioned via tiie user interfece 
into a plurality of control strategy modules, and die plurality of control strategy modules 
being selectively distributed among tiie field device, controller and workstation, tiie control 
strategy modules operating mutually independentiy and in parallel. 

22, A process control system (100) comprising: 
afield device; 

a control means coupled to tiic fidd device for controlling die fidd device; 
an interfecc means coupled to tiie control means for interfacing the control process system to a user, 
and 

a control strategy means for defining, creating, modi^ing, and implementing a process control 
strategy under direction of Uie user, the user sdcctivdy ^portioning tiie control strategy 
means into a plurality of controlstrategy modules, and the user sdectivctydistnliutingtiic 
control strategy modules among tiic fidd device, control means and interfecc means, tiie 
control strategy modules operating mutually indqwndently and in parallel 

23. A process control system according to eitiier Claim 21 or Claim 22, wherdn: 

tiic software system fiirtiier inchides a user imerface for interfacing 
user; and 
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the oontiol stxat^gy is selectivety defined, created, modified, and apportiotied, and the pluiali^ of 
control stcategf modules selectivety distributed by the user. 

24. A process control system according to cither Claim 21 or Claim 22, wherein: 
the field device includes a control elcmrat; and 

the software system includes a conUol strategy module that is distributed to the field device control 
dement 

25. Aprocess control system according to cither Claim 21 or Claim 22 whexein: 
the field deWce is a Fieldbus standard device includiiig a control elemeitt; and 

a control strategy module is distributed to the control element and operates selectively as a Fiddbus 
standard fiuK^tion block or a custom, user-defined control module. 

26. A process control system according to either Claim 2 1 or Claim 22 wherdn the software system 
turther includes: 

a configuration program for defining, ciealing and configuring the control strategy modules and 

installing the control strategy modules among the field device, controUo- and workstation, 
the distributed controllers retaining the configuration until reconfigured 

27. A process control system according to either Claim 21 or Claim 22, wherein: 

the control strategy modules are selectivety defined, modified, and aeated by a user creating custom 

control strategy modules; and 
the control strategy modules are selectively distributed by transferring a selected control strategy 

module to a selected one of the fidd device, controller and workstatioiL 

28. A process control system according to cither Claim 21 or Claim 22 wherein the plurality of 
control strategy modules are configured into a communication services hierarchy induding: 

a remote cibjea communications (ROC) levd for communicating messages between two control 

strategy modules in a same controller and between two control strategy modules in different 
controUos, and 

a low levd communications levd for inteifadng with communications hardware and transmitting 
messages across the communications hardware. 

29. A method of operating a process control system (100) induding a distributed controller (1 10) 
and a distributed fidd device comprising the stq>s o£ 

executing process control operations; 

executing an editor program during execution of the process control system operations; 
using the editor program, defining a control strategy induding the stq>s of : 
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building a plurality of function blocks (522) and control modules (440); and 
downloading user-specified function blocks and control modules sdectivcly among the 
distributed conlroller and the distributed fidd device; 
executing the function blocks and control modules distributed to the controller and distributed to the 
field device mutually independently and in parallel. 

30. A computer program product for use in a process control system (100) including a field device, a 
controller (1 10) coupled to the field device, and a workstation (102) coi^led to the controller, the computer 
program product oon:q)rising: 

a conqmtcr usable medium having conqnitablc readable code embodied therein inchiding a software 
system iny)lcmcnting a control strategy for the process control system, the control strategy 
being selectively definable, crcatable, modifiable, and apportionable into a pluraUQr of 
control strategy modules, and the plurality of control strategy modules bdng selectively 
distributable among the field device, controUer and woricstation, the control strategy 
modules operating mutually independently and in parallel 

31. A process control system (100) comprising: 

a field device including a source of diagnostic informatioru 
a controller (1 10) coi^led to the field device; 

a woricstation (102) coiq)led to the controller and inchiding a user inteiface (300); and 
a software system implementing a diagnostic monitoring and display program for the process control 
system, the diagnostic monitoring and display program including: 
a plurality of diagnostic modules selectively defined and created via the user interface for 
access using the diagnostic monitoring and display program, die plurality of 
diagnostic modules upon creation being selectively distributed among tiie field 
device, tiie controller and tiie workstation, tiie diagnostic modules operating 
mutual^ independentiy and in parallel accessing the source of diagnostic 
informatior^ and 

a display routine for accessing diagnostic information from the phirality of diagnostic 

modules and displaying the diagnostic information accessed fiom the pluraUfy of 
diagnostic modules unifonnty for all diagnostic modules in the process control 
system so that the diagnostic information relatiiig to a process that operates both in 
the controller and in the field device is displayed in the same manner regardless of 
die source of the diagnostic information. 

32. A process control system (100) comprising: 

a field device including a source of diagnostic information; 

a controller (110) coupled to the field device; 
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4 a workstation (102) coupled to the controller and including a user interfece (300); and 

5 a software system implementing a diagnostic monitoring and display program for the process control 

6 system, the diagnostic monitoring and display program including: 

7 a plurality of control modules (440) for selectively implementing a process control strategy, 

8 a plurali^ of diagnostic modules selectivdy defined and created via the user interface for 

9 access using the diagnostic monitoring and display program, the plurality of 

diagnostic modules upon creaUon being selectively distributed among the field 

^ * device, the controller and the workstation, the diagnostic modules operating 

mutually indepcndcntiy and in parallel accessing the source of diagnostic 

^3 information; and 

^ * displ^ routine for accessing diagnostic information from the plurality of diagnostic 

modules and a control scheme from the plurality of control modules and for 
respectively displaying the diagnostic information accessed from the plurality of 
diagnostic modules and the control strategy accessed from the plurality of control 
modules so that the diagnostic information and the control information are 

1^ accessed in the same manner. 

1 33. A process conuol system (100) comprising: 

2 a plurality of field devices, a field device of the plurality of field devices including a source of 

3 diagnostic information; 

4 a plurality of controllers (110), a controller of the plurality of controllers being coupled to a field 

5 device of the plurality of field devices; 

6 a workstation (102) coupled to the conUoller and including a user interface (300); and 

7 a software system implementing a diagnostic monitoring and displ^ program for the process control 
* .{* system, the diagnostic monitoring and display program including: 

^ * plurality of diagnostic modules selectively defined and created via the user interface for 

access using the diagnostic monitoring and display program, the plurality of 

^ ^ diagnostic modules upon creation being selectively distributed among the field 

devices, the controllers and workstation, the diagnostic modules operating 

1^ mutually independently and in parallel; and 

14 a displ^ routine for accessing diagnostic information from the plurality of diagnostic modules 

• operating mutuaUy independently on the field devices, the controllers and the workstation 

- i ^<**splagring the diagnostic information accessed from the plural 

uniformly so that the diagnostic information relating to a process that operates more than 
of field devices, the controllers and the workstation is displayed as being generated 
19 at a single location. 
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1 34. A process control system (100) cx>inprising: 

2 a plurality of field devices, a field device of the plurality of field devices induding a source of 

3 diagnostic information; 

4 a plurali^ of control means for controlling a field device, a control means of the plurality of control 

5 means being coupled to a field device of the plurality of field device^ 

6 an intei&ce means coiqiled to the pfauali^ of control means for intei&cing the control process 

7 system to a user, 

8 a diagnostic means for in^lemenfing a process control strategy, the diagnostic means bdng 

9 selectively defined and created as a pluraliQr of diagnostic modules, the plurality of 

10 diagnostic modules upon creation being selectively distributed among the field device, 

11 control means and interface means, the diagnostic modules operating mutually 

12 independently and in parallel; and 

13 a display means for accessing diagnostic information from the plurality of diagnostic means 

14 operating mutually independentiy on the field devices, the control means and the interface 

15 means and displaying the diagnostic information accessed from the plurality of diagnostic 

16 modules uniformly so that the diagnostic information relating to a process that operates 

17 more than one of the fidd devices, the control means and the inteifice means is di^layed 

18 as being generated at a single location. 

1 35. A process control ^stem (100) comprising: 

2 a field device including a source of diagnostic information; 

3 a controller (1 10) coupled to the field device; 

4 a workstation (102) coupled to the controller and including a user interface (300); and 

5 a software system in^>lementing a diagnostic monitoring and display program for the process control 

6 system, the diagnostic monitoring and display program including: 

7 a control strategy for the process control system, the control strategy being selectively 

8 af^Nutioned into a plurality of control strat^ modules and selectively distributed 

9 among the field device, controller and workstation, the control strategy modules 

10 q)ei:atingmutualfytndq)endent]yandinparalld; 

11 a plurality ofdiagnostic modules selectively defined and aeated via the user interf^ - 

12 access using the diagnostic moiutoring and display program, the plurality of 

13 diagnostic modules upon creation being selectively distributed among the field 

14 device, the controller and the workstation, the diagnostic modules operating 

15 mutually indq)cndenUy and in parallel accessing the source of diagnostic 

16 information; and 
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^'^ * display loutiiie for accessing diagnostic infonnation from the plurality of diagnostic 

modules and displaying the control strategy and the diagnostic information 
acxessed from the plurality of diagnostic modules uniformly so that the diagnostic 
information relating to a process that operates both in the controller and in the 

2^ field device is displayed as being generated at a single location. 

1 36. Aprocesscon!rolsiystcmaocordingtoanyofClaims31, 32,33,34,and35 wherein 

2 the plurali^ of diagnostic modules arc selectively defined and created, and selectively distdbuted by 

3 auser. 

1 37, A process control system according to any of Claims 31. 32, 33, 34, and 35, wherein: 

2 the field device includes a oontrol element; and 

3 a diagnostic module of the plurality of diagnostic modules is distributed to the field device and 

4 monitors a condition or status of the control element 

y A process conUol system according to any of Claims 31.32. 33, 34, and 35, further comprising: 

2 . a networic coupled to the controller; and 

3 an external node coupled to the controUer through the nctworic so that device information including 

4 real-time data, history information, event statistics, configuration data and diagnostic 

5 information are accessed using network standard communications. 

1 39. A computer program product comprising: 

2 a computer usable medium having computable readable code embodied therein for controlling a 

3 process control system (100) including a source of diagnostic information, a controller 

4 coupled to the field device, and a workstation (102) coupled to the controller and including 
^ ^ interface (300), the executing program code implementing a diagnostic monitoring 

^ ' ^ display program for the process control system, the diagnostic monitoring and display 

7 program including: 

8 a plurality of diagnostic modules sdectiveiy defined and created via the user interface for 

9 access using the diagnostic monitoring and display program, the plurality of 

: dij^gnostic modules upon creation being selectively distributed among the field 

device, the oontioller and the woricstation, the diagnostic modules operating 

inutually independently and in parallel accessing the source of diagnostic 
^3 information; and 

a display routine for accessing diagnostic information fix)m the plurality of diagnostic 

modules and dispkQdng the diagnostic information accessed firan the plurality of 

diagnostic modules imiformfy for all diagnostic modules in the process control 

system so that the diagnostic information relating to a process that operates both in 
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1^ the oontrollcr and in the fidd device is displs^red in the same manner legardless of 

19 the source afthe diagnostic information 

1 40. A conq>utcr program product comprising: 

2 a computer usable medium having conq>mable readable code embodied th^n for controlling a 

3 process control system ( 100) including a field device having a source of diagnostic 

^ information, a controller coupled to the field device, a workstation (102) coupled to the 

5 controUer, and a user intei&ce (3 00). the conqmtable readable code inqilemcntmg a 

6 diagnostic monitoring and display program for the process control system, the diagnostic 

7 monitodng and displ^ program induding: 

8 a plurality of control modules (440) for selecth^ implementing a process control strategy; 

9 aphiralityof diagnostic modules sdectivetydefiried and created via the user interfoce for 

10 access using the diagnostic monitoring and display program, the plurality of 

1 1 diagnostic modules upon creation being sclectivdy distributed among the field 

12 device, the controller and the woricstation, the diagnostic modules operating 

13 mutually independently and in parallel accessing the source of diagnostic 

14 information; and 

1^ a display routine for accessing diagnostic information firom the plurality of diagnostic 

1^ modules and a control scheme from the plurali^ of control modules and for 

1^7 respectively di^laying the diagnostic infonnation accessed fit>m the plurality of 

1 ^ diagnostic modules and the control strategy accessed fi:om the plurality of control 

19 modules so that the diagnostic information and the control information are 

20 accessed in the same manner. 

1 4 1 . A control system for controlling a process comprising! 

2 a controller coi^>led to the process; and 

3 a software system executing on the controller and implementing a control strategy for controlling the 

4 process, the control strategy being defined by a layered hierarchy of modules including 

5 elemental modules containing exclusively one or more primitives and composite modules. 

1 42. A pnxxss control system (100) for controlling a phuality of field devices, the process control 

2 system comprising: 

3 apluralityofdistxibotedcontroUers(110)a)upledtotiiefidddevicesforcontroltingapio^ 

4 a distnlmted software system executing on the plurality of distributed controllers and implementing 

5 a control strate^r for controlling the process, the control strata bdng defined by a layered 

6 hierarchy of modules distribnted for execution among the plurality of distributed 

7 controllers, the hierarchy of modules including elemental modules containing cxchisivety 

8 one or more primitives and conqxisite modules. 
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1 43. A process control system (100) comprising: 

2 a plurality of field devices; 

3 a plmalily of distributed controUers (1 10) coupled to the field devices for controlling a process; and 

4 a distributed software system executing on the plurality of distributed controUers and impipm^nj. 

5 a control strategy for controlling the process, the control strategy being defined by a leered 
^ hieraichy of modules distributed for execution among the plurality of distributed controUcis 

7 and the pluiaUty of field devices, the hierarchy of modules including elementai modules 

8 containing exchisively one or more primitives and composite modules. 

1 44. Acontrolsystcmforcontrollingaprocessunderdirectionofauser.thecomrols^^ 

2 comprising: 

3 a controller (1 10) covqpled to the process; and 

4 a software system executing on the controller and implementing a control strategy for controlling the 

5 process, the control strategy being defined by a plurality of control modules (440) which arc 

6 objects of a container dass. a control module of the plurality of control modules having a 

7 specified task and a predefined external interface, the control module being encapsulated in 

8 ^'^^ software system and accessed through the predefined external interface 

9 control module is user-modifiable. 

1 45, A control system according to any of Claims 4 1, 42, 43, and 44 wherein: 

2 the process includes a field device; and 

3 an elemental module is an elemental fiinction block defined in accordance with a Fieldbus standard 

4 protocoL 

1 46. A control system according to any of Claims 4 1, 42, 43. and 44 fiuthfir comprising: 

2 a user interface coupled to the controUer for spcci^ng the control strategy, the control strategy 

3 being user-specified by a module type of constituent elemental modules and composite 

4 modules, by interconnections between the constituent modules and by input/ output 
^ connections of the constituent modules. 

1 47. A control system according to Gaim 46wheiein: 

2 the user inter&x; for modifying the control strategy is implemented in a plurality of process control * 

3 programming languages. 



1 48. A control system according to any of Claims 41. 42. 43. and 44 wherein the software system 

2 ftmher includes: 
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a configuration program for defining the oontiDl strategy and inslaUing tbe control strategy on the 
controller, the contiolier retaining the configuration onlU reconfigured. 

49. A computer program prodoct o ompri ring- 

a computer usable medium having conqnitable readable code embodied therein for controlling a 
process control system (100) for controlling a plurality of field devices, be process control 
system inchiding a phirality of distributed controllers (1 10) coupled to die field devices for 
controlling a process, the conqmtable readable code including. 

a distnlmted software system executing on the plurality of distributed controUers and implementing 
a control strategy for controlling the process, the control strategy being defined by a layered 
hierarchy of modules distributed for execution among the phualiiy of distributed 
controllers, the hierarchy of modules inchiding elemental modules containing exclusive^ 
one or more primitives and composite modules. 



50. 

a computer usable medhun having computable readable code embodied therein for controlling a 
process control system (100) inchiding a plurality of field devices and a plurality of 
distributed controllers (1 10) coupled to the field devices for controlling a process, the 
computable readable code including: 

a distributed software system executing on the plurality of distributed controllers and implementing 
a control strategy for controlling the process, the control strategy being defined by a layered 
hierarchy of modules distributed for execution among the pluraUty of distributed controllers 
and the plurality of fidd devices, the hierarchy of modules including elemental modules 
containing exclusively one or more primitives and composite modules. 

51. A process control system (100) comprising: 

a process; 

a plurality of controllers (1 10) coapled to the process; 

a woikstation (102) coupled to the plurality of controUers and including a user imeifiice (300); and 
a software system including a network operating system and implementing a routine for 

automatically sensing a connection of a controUer to a network and incorporating the 

controller into the network operating system. 

52. A process control q«temaccording to Claim 51 wherein the software q^fortte 

a software routine responsive to automatic sensing of a oomiection of a controller to the network for 
automatically configuring an input/output (I/O) subsystem in a control system. 
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1 53. A process control system according to Claim 5 1. wherein the routine for automatically sensing a 

2 connection of a controUer to a network and incorporating the controMcr into a network operating system 

3 comprises: 

4 means for connecting a controller to the network; 

5 "»«^oP««^ivcinthcconiiecte^ 

^ assignment, the request being acconqianicdiqr the controU^ 

7 address; 

S a network configuration service iticinrfwig- 

9 means for lecetving the request to confirm; 

means for searching a tabic of configured devices for a matching MAC address; 
* ^ ™^ operative when the MAC address matches for generating device and network 

information including a network address from a device table; 
operative when the MAC address does not match for generating device and network 
*n^orn»tioninduding a networic address from MAC address^^^ 
information and adding the default information to the device table; and 
16 ^ means operative wiicn the MAC address does not match for assigning the connected controller 

control cither as a new device added to the device table or as a device 
configuration previously existing in the device table. 



10 



2 "^wntr^^^ a^^wr^^mg^ysi^m ^'"'^ 

3 connecting a controller to the network; 
sending, by the connected controller, a request to confirm a network address assignment, the 

request being accompanied by the controller media access control (MAC) address; 
receiving, by a network configuration service, the request to confirm and responding by peifonning 

7 the stqjs of: 

8 searching a table of configured devices for a matching MAC address; 

^ when the MAC address matches, generating device and network information including a 

network address from a device table; 

when the MAC address does not match, generating device and network information 

including a netwodc address fi^om MAC address-based de&ult information and 
adding the de&ult information to the device table; and 
14 when the MAC address does not match, assigning the connected controller under user control cither 

as a new device added to the device table or as a device configuration previously existing in 
1^ the device table. 
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55. A metliod of automatically configuring an input/output (I/O) subsystem in a control system 
conqnising the steps of : 

imcnogating an I/O Card at a nser-spodfied card position to dcteminc a Card Type and a number 

ofl/O Ports in the I/O Card; 
determining wh^er the interrogated I/O Card is previously defined in an oigineering dat^ase; 
if the I/O Can! is not pievioudy defined in the engineering database^, defining M 

suitable lype and I/O Ports of a suitable number, the suitable type and number being 

predetermined for the card position^ 
interrogating the I/O Ports of an I/O Card in accordance with the Card Type to determine a Port 

Type and a number of I/O Devices on the I/O Port; 
if the I/O Port is not previously d^ed in the engineering database for the port address, defining ai 

I/O Port of a suitable type and I/O Devices of a suitable number, the suitable ^e and 

number being predefined; 
interrogating the I/O Devices in accordance with the Port T>pe to detennine a Device Type; 
if the I/O I>nfice is not previously defined in the engineering database for 

defining an I/O Device of a suitable the suitable Qt>c bdng predefined; and 
oeating instrument signal tags OSTs) for primary signal sources on the I/O Ports and the I/O 

Devices. 



56. A method according to Claim 55, further comprising the steps of: 

determining whether an I/O Card exists in the engineering database for the card position; 

if the I/O Card exists in the engineering database, determining whether the Card T>pc in the 

engineering database matches the Card Type sensed at the card position, 
if the Card Type in the aiginecring database does not match the Card Type sensed at the card 

position executing the steps of: 

generating a graphic notification of the mismatch; 

interrogating a user to detennine whether the engmeering database is to be changed to 
include the sensed Card T^pe; and 

changing the Card in the «iginecring dat^ase to the sensed Card 
user. 



57. A method according to Claim 55, fimhorconqnising the stqis of 

d^cnnining whether an I/O Port exists in the engineering database for the port address; 

if the I/O Port exists in the engineering database, determining whether the Port Type in the 

engineering database matches tiie type of the sensed I/O Port sensed at the port address; 
if the Port Type in die engineering database does not match the type of the sensed I/O Port executing 

the stqis of: 
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7 requesting advisement of the user to determine whether the engineering database is to be 

5 updated to match the sensed I/O Port; and 

9 changing the Port Type in the engineering database to the sensed Port Type if requested by 

10 the user. 

1 58. A method according to Claim 55, further coniprising the steps of: 

2 dctcnnining whether an I/O Device esdsts in the engineeri^ 

3 if the I/O Device exists in the engineering database, detennining whether the Device Type in the 

4 engineering database matdies the type of the sensed yOD 
5' address; 

6 »*'^el>cvicc Type in the engineering database does not match the t^ 

7 executing the steps of: 

8 requesting advisement of the user to determine \^her the engineering database is to be 

9 updated to match the sensed I/O Device; and 

changing the Device Type in the engineering database to the sensed Device Type if 

11 requested by the user. 

1 59. A computer program product comprising: 

2 a computer usable medram having computable readable code embodied therein for automatical^ 

3 sensing a connection of a controller to a networic and incorporating the controller into a 
-^^^^^^^ networic operating system including: 

^ " ' a routine for connecting a controller to the networic; 

6 a routine for sending, by the connected controller, a request to confirm a network address 

7 assignment, the request being accompanied by the controller media access control 

(MAC) address; 

9 a routine for receiving, by a networic configuration service, the request to confirm and 

1^ responding by executing routines including: 

^ * a routine for searching a table of configured devices for a matching MAC address; 

a routine for determining when the MAC address matches, and for a matching 

address generating device and networic information including a networic 

address fern a device table; 
^ ^ a routine for determining when the MAC address does not match, and for a 

no nm a tchi n g address generating device and networic information 

including a network address jfrom MAC address4iased default 
1^ information and adding the de&uh infonnation to the device table; and 

a routine for determining when the MAC address does not match, and for a 

nonmatching address assigning the connected controller under user 
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^ ' control cither as a new device added to the device table or as a device 

configoration previously existing in the device table. 

1 60. A compoter program product comprising: 

2 a computer usable medium having computable readable code embodied thacin for automaticalty 

3 configuring an input/output (I/O) subsystem in a control system comprising: 

^ ^ ^^^^ interrogating an I/O Card at a user-specified card position to determine a Card 

^ T^pe and a number oflAD Ports in the I/O Card; 

6 a routine for detmnining whether the interrogated I/O Card is previously defined in an 

^ engineering database; 

8 a routine operative vifhesa the VO Card is not previously defined in the engineering database 

9 and defining an I/O Card of a suitable ^ and IAD Ports of a suitable numbCT, the 

suitable type and numbar being predetermined for the card position; 

^ * ^ ^^^^^ for interrogating the I/O Ports of an I/O Card in accordance with the Card Type to 

determine a Port Type and a number of I/O Devices on the I/O Port; 
^ ^^^^^ operative v/hen the I/O Port is not previously defined in the engineoing database 
fo"^ port address, the routine defining an I/O Port of a suitable lype and I/O 
Devices of a suitable number, the suitable type and number being predefined; 
» routine for interrogating the I/O Devices in accordance with the Port Type to determine a 
17 Device!^; 

^ routine operative when the I/O Device is not previously defined in the engineering 

database for the device address, the routine defimng an I/O Device of a suitable 
20 type, the suitable type being predefined; and 

a routine for creating instrument signal tags (ISTs) for primary signal sources on the I/O 
22 Ports and the I/O Devices. 

1 61, A process control system (100) comprising: 

2 a process; 

3 a plurality of devices coupled to the process; 

4 a conununication network coupled to the devices; 

5 a workstation (102) coupled to the pluraUty of devices via the netwodc and including a user interface 

6 (300); and 

7 a software system executable on the network and implementing a routine for automatically sensing a 

8 connection of a device to a network and placing the connected device in an accessible state 
^ for commimicating with a user via the user interface. 

1 62. A control system comprising: 

2 a nefworl^ 
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3 a pturalitsrofdevices coupled to the aetwotk; 

4 a distributed oontroUer coiq>led to the phiiality of devices and controUing the phiiality of devices 

5 according to a defined control configuration, the distributed controller including: 

6 a control logic for sensing a device that is connected to the network but not included in the 

7 defined control configuration; 

g a control logic for supplying initial interconnect information to the connected device; and 

9 a control logic for uploading configuration parameters firom the connected device to the 

10 distributed controller. 

1 63 . A process control system according to either Gaim 6 1 or Claim 62 wherein the software system 

2 - further comprises: 

3 a routine for configuring the connected device in a network control configuration of the plurality of 

4 devices. 

1 64. A process control system according to Claim 63 wherein the routine for configuring the 

2 connected device further oonqirises: 

3 a user-interactive routine for determining a device type of the connected device; 

4 a user-interactive routine for determining a role of the connected device with respect to the process 

5 control system; 

6 a user-interactive routine for assigning a physical device tag the determined role; and 

7 a user-interactive routine for verifying connection of the device to the network. 

1 65. A process control system according to Claim 63 wherein the routine for configuring the 

2 connected device further conq>rises: 

3 a user-interactive routine for initiating calibrating the connected device; and 

4 a user-interactive routine for configuring the device within an overall control scheme of the process 

5 control system 

1 66. A process control system according to either Claim 6 i or Claim 62 wherein the software system 

2 further comprises: 

.3. a routine for commissioning the connected device including: 

4 a us^-interactive routine for assigning a physical device tag, a device address, and a device 

5 identification to the coimected device, and 

* 6 auser-interactrveioutineforinstallingacontrolstrategyto the digital device. 



67. A method of configuring a control system comprising: 
predetermining a configuration of devices coupled to a networic; 
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3 sensing a connection to the netwoik of a device that is not included in the predetennined 

4 configuration; 

5 assigning the connected device a standby address nliich allows access to device infonnatton and 

6 configuration parameters of the connected device; 

7 commissioning the connected device into an operational state in commmiication with the control 

8 system; and 

9 configuring the connected device in combination with the predetermined configuration of devices. 



1 68. A method according to Claim 67 whetgin cnttupiiyfff nning th** en^p^^ d^<y finthfT 

2 Gon^rises: 

3 assigning to the connected device a physical device tag, a device address, and a device identification; 

4 installing a control strategy to the connected device; and 

5 placing the connected device in an operational state in communication with the network. 

1 69, A method according to Claim 67 wherein configuring the connected device fiirthcr comprises: 

2 interrogating the connected device to determine a device type; 

3 determining a role of the connected device in the context of the predetermined configuration; and 

4 assigning a physical deWce tag so that the determined role is set 

1 70. A computer program product conqnisuQg: 

2 a computer usable medium having computable readable code embodied therein for configuring a 

3 control system including: 

4 a routine for predetermining a configuration of devices coupled to a network; 

5 a routine for sensing a connection to the network of a device that is not included in the 

6 predetermined configuration; 

7 a routine for assigning the connected device a standby address which allows access to device 
S ioformation aiui configuration parameters of the connected device; 

9 a routine for coirmiissioning the conneaed device into an (^erational state in communication with 

10 the control system; and 

^1 a routine for configuring the connected device in conibination with the predetermined configuration 

12 of devices. 

1 71. A process control system (100) for controlling a process according to a control strategy, the 

2 process control system comprising: 

a computer syst^ including a processor, an input mtfrxf^fx and a di^l^ coq)l6d to the process; 
a field device coupled to the process; 

a controller coupled to the field device and commimicativdy coupled to the compatci system; and 
a software system including: 
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7 an interactive, user-directed process configuration program including a plurality of control 

S language editors for selecting the control strategy using a control language selected 

9 from a plurality of control languages, the process configuration program creating 

10 an executable control module and downloading the executable control module 

1 1 selectively among the computer system, the field device, and the controller, and 

12 an executable control module selectively created, downloaded and executed, the control 

1 3 module being configurable by the process configuration program to configure a 

14 control language execution engine. 

1 72. A process control system (100) comprising: 

2 a field device; 

3 a controller (1 10) coiqiled to the field device; 

4 a workstation (102) coupled to the controller and having an interactive input interface and a display; 

5 ' and 

6 a software system including: 

7 a user interface (300) responsive to the interactive input interface for interfacing the process 
- S control system to a user, 

9 a routine for implementing a control strategy for the process control system, the control 

10 strategy being selectively apportioned into a plurality of control modules (440) 

1 1 and selectively distributed among the field device, the controller, and the 

12 woricstation; and 

13 an interactive, user-directed process configuration program including a plurality of convol 

14 language editors for selecting the control strategy using a control language selected 

15 from a pluralityr of control languages, the process configuration program 

16 selectively creating the control modules implementing the control strategy, 

17 selectively apportioning the control modules, and selectively distributing the 

18 control modules among the field device, the controller, and the woricstation for 

19 executing the control strategy. 

1 73. A process control system (100) for controlling a plurality of field devices of multiple different 

2 field device types, the process control system comprising: 

3 a plurality of controllers (1 10) coiqiled to the field devices; and 
.4 a software system including: 

S a user intexfim (300) for imerfluing the process control system to a user, 

a plurality of control modules (440) selectively created, dowoloaded, and executed on ones 
of the plurality of controllers, the software system for communicating with the 
multiple different field device types and for controlling the multiple different field 
devices indqpeiulently of control of control modules in other field devices; and 
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an interactive, nscr-diiected pn)cess configuration program including a plurality of control 
language editors for selectively installing and configuring the control modules 
using a control language selected finom a plurality of control languages. 

74. A process control system according to Claim 71, Claim 72 or Claim 73, wherein: 
the scrflware system is distnbuted among the processor and the controUer indudiiig: 

an interactive iiqrat and displ^ routine executable on the processor, a^ 
a plmality of control language execution engines executable on the controller for 
implementing reflective languages of the phirality of cmitrol languages. 

75. AprocesscontrolsystcmaccQrdingtoClaim71,Ciaim72,orClaim73fiirtherTO^ 
a plurality of field devices; 

a plurality of contralleis coupled to the field devices, wherein: 

the software system is distributed among the workstation and the plurality of conlroUers and 
includes: 

an interactive iiqmt and displ^ routine executable on the workstation, and 

a plurality of control language execution engines selectively created, apportioned, 

disciibuted, and executable on the plurality of oontrollere for implanenting the 

plurality of control languages. 

76. A method for configuring a process control environment, the process control environment 
including a computer system having a processor coupled to a display device, the method comprising: 

providing a plurality of instructional sections, an instructional section setting forth information 

relating to configuring the process comrol environment; 
selecting a control language editor for defining a process control environment configuration; 
activating the selected control language editor; 

displaying, on the displ^ device, a sequence of configuration screen presentations relating to the 
instniction sections as directed in terms of the selected control language editor, and 

guiding a user through the configuration of the process control environment via the sequence of 
configuration soeen presentations; 

interactively creating a phirality of indq)endent control modules (440); 

configuring the plurality of control modules to create a control totegy; 

transferring the control strategy to a selected controller executing a control language execution 
engine corresponding to the selected control language editor, the selected controUer 
execudng the control strategy independently of execution of other control strategies. 



77. A computer program product comptisiiig: 
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a computer usable medium having computable readable code embodied therein for controUing a 
process control system (100) according to a control strategy, the process control system 
inchiding a computer system with a processor, an input interface and a display coupled to 
the process; a Geld device coupled to the process; a controUcr coupled to the fieU device 
and communicatively coupled to the computer system; and a software system further 
including: 

an interactive, user-directed process configuration program including a plurality of control 
language editors for selecting the control strategy using a control language sdected 
torn a phirality of control languages, the process configuration program cteating 
an executable control module and downloading the executable control module 
sdectivdy among the computer system, the field device, and the controller, and 

an executable control module selectively created, downloaded and executed, the control 
module being configurable by the process configuration program to configure a 
control language execution engine. 

78. A computer program product comprising: 

a computer usable medium having computable readable code embodied therein for managing a 
process control system (100) including a field device, a controller coupled to the field 
device, a woikstation (102) coupled to the conuoUer and having an interactive input 
inteifece and a display, and a software system inchiding: 

a user interface (300) responsive to the interactive input interface for inteifedng the process 

control system to a user, 
a routine for implementing a control strategy for the process control ^stem, the control 

strategy being selectively apportioned into a plurality of control modules (440) 

and selectively distributed among the field device, the controller, and the 

workstation; and 

an interactive, user-directed process configuration program including a plurality of control 
language editors for selecting the control strategy using a control language selected 
from a plurality of control languages, the process configuration program 
selectively creating the control modules iiiq)lementing the control strategy, 
selectively apportioning the control modules, and selectively distributing the 
control modules among the field device, the controller, and the wo Astation for 
executing the control strategy. 

79. A computer program product con^iising: 

a conq)utcr usable medium having computable readable code embodied therein for controlling a 

plurality of field devices of multiple different field device types, the process comxdL system 
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8 



4 (100) including a pliuatity of controllers (1 10) coupled to the field devices and a sofhvaie 

^ system including: 

6 a user interface (300) for interfacing the process control system to a user, 

7 a plurality of control modules (440) selectively created, downloaded, and executed on ones 

of the phuality of controllers, the software system for communicating with the 

9 nmltqde dififenait field device types and for controUing the multiple dififerent field 

devices indq)endently of control of control modules in other field devices; and 
^ ^ ^ interactive, nser-diiected process configuration program including a phirality of control 

* ^ language editors for sdectivety instiling and configuring the control modules 

using a control language selected from a plurality of control languages. 



13 



3 
4 
5 
6 



1 80. A cotxtputcr program product comprising: 

2 a computer usable medium having computable readable code enAodied therein for configuring a 
process control environment, the process control environment including a computer system 
having a processor coupled to a display device and a software system including: 
a routine for providing a plurality of instructional sections, an iustructional section setting 

forth information relating to configuring the process control environment; 
7 a routine for selecting a control language editor for defining a process control environment 

S configuration; 

9 a routine for activating the selected control language editor, 

a routine for displaying, on the display device, a sequence of configuration screen 
^ * presentations relating to the instruction sections as directed in terms of the selected 

*2 control language editor; and 

a routine for guiding a user through the configuration of the process control environment 
via the sequence of configuration screen presentations; 
15 a routine for interactively creating a pluraUty of independent control modules (440); 

1^ ^ routine for configuring the plurality of control modules to create a control strategy; 

1^ a routine for transferring the control strategy to a selected controUer executing a control 

language execution engine corresponding to the selected control language editor, 
the selected controller executing the control strategy indq)endently of execution of 



10 



19 



2^ other control strategies. 

1 81. A process control system (100) conq)rising: 

2 a fidd device including a source of event condition information; 

3 a controllCT (1 10) coiq)led to the field device; 

4 a woikstation (102) coupled to the controller and induding a user interface (300); and 

5 a software system implementing an event condition momtoring and displ^ program for the process 

6 control system, the event condition monitoring and display program inchiding: 
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a plurality of oontiol modules (440) including event attributes, the control modules being 
selectively conlroUed and selectivdy distributed among the field device, the 
controUer and the workstation, the control modules operating mutually 
indcpcndemly and in paraild acoimulaUng event condition information; 

a display routine for accessing the event condition information horn the phuality of control 
modules and displaying the event condition information accessed fiom the 
phuality of control modules in an order of priority selected by a user, and 

a configuration routine for user-selcctively defining and creating the control modules and 
the event attributes of the control modules, and for user selectively distributing the 
control modules among the field device, the controller, and the woricstation. 

82. A process control system according to claim 81, wherein the software system fiuther comprises: 
a routine for priming the event attributes with a currcnt alarm set subject to a current user 

responsibility scope to begin accumulating an event count when a new user logs-on, 

83. A method for operating a process control system (100) comprising the steps of: 
defining a plurali^ of conditions as events, the events being associated with a plant area; 
activating an event journal for logging event conditions; 

configuring an alarm behavior inchiding the steps of: 

creating an alarm attribute, the alarm attribute being selectively created in a control module 

or in an equipment module; 
selectively disabling or enabling the created alarm attribute; 
selectively placing an enabled alarm attribute in an acknowledged state or an 

unacknowledged state; and 
selectively placing the alarm attribute in an active state or an inactive state; 
selecting a priority for the alarm attribute; and 
consolidating a plurality of active alarm conditions into a subset of highest priority alarms. 

84. A conq;>uter program product comprising: 

a computer us^le medium having computable readable code embodied therein inc process 
control system (100) including a field device including a source of event condition 
information, a controller coupled to the field device, and computer coupled to the controller 
and inchiding a usct interface (300), the computer program product including an event 
condition monitoring and displ^ program for the process control system, the event 
coiuiition monitoring and display program inrl wiing' 

a plurality of control modules (440) inchiding event attributes, the pluraU^ of control 
modules being selectively controlled and selectively distributed among the field 
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device, the conlroUer and the woikstatioii. the control modules opeiating niutaally 
indepaufcntly and in parallel accumulating event condition infonnation; 

a display routine for accessing the event condition infommtion from the plurality of control 
modules and diq)Uying the event condition infonnation accessed from the 
pluralily of control modules in an order of priority selected by the user, and 

a oonilgmation routine for user^ectively defining and creating the control mtidules and 
the event attrilnites of the control modules, and for user selectivBty 
control modules among the field device^ the controller, and the innkstation. 

85. A computer program product comprising: 

acomputer usable medium having computable readable code embodied thettinim^ 
control system (100) further including: 

aroutine for definingaplurality of conditions as events, the events being associated 
idantaiea; 

a routine for activating an event journal for logging event conditions; 
a routine fix configuring an alarm behavior including: 

a routine to creating an alarm attiibutei the ahum attribniB bang sdectiv 
created in a control module or in an equipment module; 

a routine for selectively disabling or enabling the created alarm attribute; 

a routine for selectively placing an enabled ahum attribute in an acknowledged 

state or an unacknowledged state; and 
a routine for selectively placing the ahum attribute in an active state or an inactive 

state; 

a routine for selecting a priority for the alarm attribute; and 
a routine for consolidating a pluraUty of active alarm conditions into a subset of 
highest priority alarms. 

86. A computer program product according to either Claim 84 or Claim 85 fimher comprising: 
aroutineforprimingthecventattributeswith a current ahum set subjea to a current user 

responsibiUty scope to begin accumulating an event comU when a new user tog^m. 

87. A compmerprogram product according to cither Qaim 84 or Claim 85. farther comprising: 
a routine for transitioning between a plurality of alarm attribute states, inchiding: 

arontine for sdcctively disabling or enabling an alarm attn^ute. the alannattt^^^^ 

in an inactive and acknowledged condition when die alarm attribute is disabled; 

a routine for configuring the alarm attnT)ute with a boolean attribute so that an alarin 

active wlum the boolean attiibBte is true and the alarm is inactive when the 
boolean attribute is true; 



wo 98^6335 



-109- 



PCTAJS98/0I573 



a routine for optionally inrating the sense of the boolean attribute with an i nvcrt attribute; 
and 

a routine for when the alam attribute is enabled, sdccthrdy acknowledging the a^ 
attribute or unacknowledging the alarm attribute. 

88. A computer program product according to cither Claim 84 or Claim 85, whoein the routine for 
<x)nsolidating a plurality of active alarm conditions includes: 

a routine for lanking an alarm condition in an order of decreasing order of piecedence based on an 
ordered priori^ including: 

a routine for first ranking an unackno^edged condition witii precedence over an 

acknowledged condition; 
a routine for second lankhig a condition in order of High selected priority. Medium seleaed 

priority, then Low selected priority; and 
a routine for third ranking a condition in order of time of detection with a newest 

timestanqi condition having a precedence over an older timestamp condition. 

89. A computer program produa according to dther Claim 84 or Claim 85, wherdn the routine f 
consolidating a plurality of active alarm conditions includes: 

a routine for user-level consolidation including: 

a routine for displaying an alarm banner in a graphical user interface (300); 
a routine for granting alarm privilege over a one or more p lant areas to a user, 
a routine for pred^ning an attribute container supporting an alarms attribute; 
a routine for constructing a display referencing the attribute container, and 
a routine for allowii^ access to highest priority alarms based on the display referencing the 
attribute container. 



90. A conq)uter program product according to either Qaim 84 or Claim 85, whei^n: 
the conditions defined as events are conditions selected from among the conditions of: 
alarms; 

alarm acknowledgments; 

usw changes inchiding attributes written by the user, methods invoked by the user, and log- 

in and log-out q>erations by the user; 
configuration changes to a run tnne system including system installation and de-installatiori 

operations; 

Sequential Function Chart (SFC) sUte changes; 
Qpmtor Attention Requests (OARs); and 

miscellaneous events including non-alarm state transitions and equipment stale changes. 
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